On 07/05/2017 04:38 PM, Benjamin Herrenschmidt wrote: > On Wed, 2017-07-05 at 21:07 +1000, David Gibson wrote: >> 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.
