[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [for-2.11 PATCH 24/26] spapr: allow guest to
From: |
Alexey Kardashevskiy |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [for-2.11 PATCH 24/26] spapr: allow guest to update the XICS phandle |
Date: |
Tue, 1 Aug 2017 12:20:56 +1000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
On 31/07/17 14:58, David Gibson wrote:
> On Fri, Jul 28, 2017 at 08:20:57AM +0200, Thomas Huth wrote:
>> On 28.07.2017 06:02, David Gibson wrote:
>>> On Tue, Jul 25, 2017 at 08:03:06PM +0200, Greg Kurz wrote:
>>>> The "phandle" property of the XICS node is referenced by the
>>>> "interrupt-map"
>>>> property of each PHB node. This is used by the guest OS to setup IRQs for
>>>> all PCI devices.
>>>>
>>>> QEMU uses an arbitrary value (0x1111) for this phandle, but SLOF converts
>>>> this value to a SLOF specific one, which is then presented to the guest OS.
>>>>
>>>> This patches introduces the new KVMPPC_H_UPDATE_PHANDLE hcall, which is
>>>> used
>>>> by SLOF to communicate the patched phandle value back to QEMU. This value
>>>> is then cached and preserved accross migration until machine reset.
>>>>
>>>> This is required to be able to support PHB hotplug.
>>>>
>>>> Note, that SLOF already has some code to call KVMPPC_H_RTAS_UPDATE, so we
>>>> have to introduce its number even if QEMU currently doesn't implement it.
>>>>
>>>> Suggested-by: Thomas Huth <address@hidden>
>>>> Signed-off-by: Greg Kurz <address@hidden>
>>>
>>> Ugh. I really, really hope we can avoid this, though I don't
>>> immediately see how. Having to have two way communication between
>>> qemu and SLOF about the device tree contents just seems like opening
>>> the door to endless complexities.
>>>
>>> This is basically a consequence of the fact that both qemu and partly
>>> responsible for constructing the device tree for the guest, and that's
>>> not easy to avoid.
>>>
>>> Hrm.. Thomas, I know it's not really the OF way, but would it be
>>> feasible to change SLOF to use the phandles as supplied by qemu rather
>>> than creating its own?
>>
>> I don't see a way to do this in an easy, clean, reasonable way. SLOF
>> uses pointers to internal structures as phandles all over the place. You
>> likely can't replace that so easily without rewriting half of the whole
>> device tree related code in SLOF, I guess...
>
> Dang, that's what I suspected.
>
> Just to be clear the phandles are used directly as raw pointers?
> There's not even some lookup macro we could change?
>
We would need to rewrite
https://github.com/aik/SLOF/blob/master/slof/fs/node.fs
Since SLOF does not seem to use phandles as pointers directly anywhere but
in nofe.fs, this should be doable. Easier said than done though.
--
Alexey
signature.asc
Description: OpenPGP digital signature
- [Qemu-ppc] [for-2.11 PATCH 21/26] qdev: pass an Object * to qbus_set_hotplug_handler(), (continued)
[Qemu-ppc] [for-2.11 PATCH 25/26] spapr_pci: drop abusive sanity check when migrating the LSI table, Greg Kurz, 2017/07/25
Re: [Qemu-ppc] [Qemu-devel] [for-2.11 PATCH 00/26] spapr: add support for PHB hotplug, Alexey Kardashevskiy, 2017/07/25
[Qemu-ppc] [for-2.11 PATCH 26/26] spapr: add hotplug hooks for PHB hotplug, Greg Kurz, 2017/07/26
Re: [Qemu-ppc] [for-2.11 PATCH 00/26] spapr: add support for PHB hotplug, Daniel Henrique Barboza, 2017/07/26