[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [for-2.11 PATCH 24/26] spapr: allow guest to update the
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [for-2.11 PATCH 24/26] spapr: allow guest to update the XICS phandle |
Date: |
Mon, 31 Jul 2017 14:58:21 +1000 |
User-agent: |
Mutt/1.8.3 (2017-05-23) |
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?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
- [Qemu-devel] [for-2.11 PATCH 20/26] spapr_events: add support for phb hotplug events, (continued)
- [Qemu-devel] [for-2.11 PATCH 20/26] spapr_events: add support for phb hotplug events, Greg Kurz, 2017/07/25
- [Qemu-devel] [for-2.11 PATCH 21/26] qdev: pass an Object * to qbus_set_hotplug_handler(), Greg Kurz, 2017/07/25
- [Qemu-devel] [for-2.11 PATCH 22/26] spapr_pci: provide node start offset via spapr_populate_pci_dt(), Greg Kurz, 2017/07/25
- [Qemu-devel] [for-2.11 PATCH 23/26] spapr_pci: add ibm, my-drc-index property for PHB hotplug, Greg Kurz, 2017/07/25
- [Qemu-devel] [for-2.11 PATCH 24/26] spapr: allow guest to update the XICS phandle, Greg Kurz, 2017/07/25
[Qemu-devel] [for-2.11 PATCH 25/26] spapr_pci: drop abusive sanity check when migrating the LSI table, Greg Kurz, 2017/07/25
Re: [Qemu-devel] [for-2.11 PATCH 00/26] spapr: add support for PHB hotplug, Alexey Kardashevskiy, 2017/07/25
[Qemu-devel] [for-2.11 PATCH 26/26] spapr: add hotplug hooks for PHB hotplug, Greg Kurz, 2017/07/26