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.
--
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
