[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE
Cédric Le Goater
Re: [Qemu-ppc] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller
Thu, 18 Jan 2018 14:27:09 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
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
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.