Re: [Qemu-devel] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Thu, 2018-01-18 at 14:27 +0100, Cédric Le Goater wrote:
> The source and the target machines should have the same realized 
> objects. I think this is the simplest solution to keep the migration 
> framework maintainable. 

Yeah well, it all boils down to qemu migration being completely brain
dead in relying on an external entity to create the same machine rather
than carrying the configuration in the migration stream... ugh.

> I don't think it is a problem to call a xics_fini() routine to 
> destroy the XICS KVM device if a new interrupt mode was negotiated
> in CAS. We would then call a xive_init() routing to create the new 
> XIVE KVM device.
> 
> When done, the question boils down to disconnect and reconnect the 
> vcpus to the KVM device. The QEMU CPU ->intc pointer should be 
> updated also but that's a QEMU level problem. Already done.

The problem is more the in-kernel hooks.
 
> In the QEMU "icp-kvm" object, the connection to the KVM device 
> is currently forced in the realize routine but we can add some 
> handlers to manage the link. Similar handlers would do the same 
> in the QEMU "nvt-kvm" object when XIVE is on.
> 
> 
> If we think this is a possible way to address the problem, I can 
> check the above thinking on a XICS KVM machine and force the 
> init/fini sequence in the CAS negotiation process. I will need 
> a KVM ioctl to destroy a device and maybe a KVM VCPU ioctl to 
> disable a capability.