On 04/12/2018 07:16 AM, David Gibson wrote: > On Mon, Feb 12, 2018 at 09:55:17AM +1100, Benjamin Herrenschmidt wrote: >> On Sun, 2018-02-11 at 19:08 +1100, David Gibson wrote: >>> On Thu, Jan 18, 2018 at 08:27:52AM +1100, Benjamin Herrenschmidt wrote: >>>> On Wed, 2018-01-17 at 15:39 +0100, Cédric Le Goater wrote: >>>>> Migration is a problem. We will need both backend QEMU objects to be >>>>> available anyhow if we want to migrate. So we are back to the current >>>>> solution creating both QEMU objects but we can try to defer some of the >>>>> KVM inits and create the KVM device on demand at CAS time. >>>> >>>> Do we have a way to migrate a piece of info from the machine *first* >>>> that indicate what type of XICS/XIVE to instanciate ? >>> >>> Nope. qemu migration doesn't work like that. Yes, it should, and >>> everyone knows it, but changing it is a really long term project. >> >> Well, we have a problem then. It looks like Qemu broken migration is >> fundamentally incompatible with PAPR and CAS design... > > Hrm, the fit is very clunky certainly, but i think we can make it work. > >> I know we don't migrate the configuration, that's not exactly what I >> had in mind tho... Can we have some piece of *data* from the machine be >> migrated first, and use it on the target to reconfigure the interrupt >> controller before the stream arrives ? > > Sorta.. maybe.. but it would probably get really ugly if we don't > preserve the usual way object lifetimes work. > >> Otherwise, we have indeed no much choice but the horrible wart of >> creating both interrupt controllers with only one "active". > > I really think this is the way to go, warts and all. >
Yes ... KVM makes it a little uglier. A KVM_DEVICE_DESTROY device is needed to cleanup the VM and a DISABLE_CAP to disconnect the vpcu from the current KVM XIVE/XICS device. I have used an extra arg on ENABLE_CAP for the moment. At the QEMU level, we need to connect/reconnect at reset time to handle possible changes in CAS, and at post_load. Destroying the MemoryRegion is a bit problematic, I have not found a common layout compatible with both the emulated mode (std IO regions) and the KVM mode (ram device regions) C.
