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... 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 ? Otherwise, we have indeed no much choice but the horrible wart of creating both interrupt controllers with only one "active". > > > > > The next problem is the ICP object that currently needs the KVM device > > > fd to connect the vcpus ... So, we will need to change that also. > > > That is probably the biggest problem today. We need a way to disconnect > > > the vpcu from the KVM device and see how we can defer the connection. > > > I need to make sure this is possible, I can check that without XIVE > > > > Ben. > > > >