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

[Cédric Le Goater]

On 01/17/2018 10:27 PM, 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 ?

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. 


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

Cheers,

C.