Re: [RFC PATCH 1/2] powerpc/xive: guest exploitation of the XIVE interrupt controller
From: Cédric Le Goater <clg@kaod.org>
Date: 2017-07-05 15:22:15
On 07/05/2017 04:38 PM, Benjamin Herrenschmidt wrote:
On Wed, 2017-07-05 at 21:07 +1000, David Gibson wrote:quoted
I don't know if it helps, but we do have the ability to trigger a full system reset from CAS, so possibly we can do the XICS/XIVE instantiation in the reset path. I don't think we use that CAS reset ability yet - we just adjust the device tree and continue the boot. But it's there if we need it. Worst comes to worst, we might have to instantiate both XICS and XIVE objects, with some flags in each indicating which is active.
we have the CAS option for that. Well, that is what I have started using in the QEMU prototype for the sPAPR XIVE support.
That could be a problem with the kernel interrupt controller. We can't really instantiate both there I think... well, actually ... maybe we could, though it's a bit messy...
Well, It would much cleaner to reset completely the guest, no ICP and no ICS objects, until we reach the end of the CAS negotiation, and then instantiate what we need. The only issue I have spotted for the moment is that the device tree is populated with IRQ numbers allocated from an interrupt source, which is way before CAS has even started. So, to work around that, we could imagine using a bitmap to allocate these IRQ numbers and then instantiate the interrupt source object of the correct type with this bitmap as a constructor parameter. Just an idea. The interrupt presenter objects could be allocated later in the boot process. I think. May be on demand, when a CPU is first notified ? I haven't looked at the gory details: migration, hotplug. But we are starting the discussion on the wrong mailing list ! Let me complete the QEMU patchset. I am currently splitting it in little chunks for a first RFC. The last one being an hideous hack to activate XIVE in the guest. Cheers, C.