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

[Alexey Kardashevskiy]

On 12/02/18 09:55, 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...
> 
> 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 ?


These days this is done via libvirt - it reads properties it needs via QMP,
then sends an XML with everything (the interrupt controller type may be one
of such properties), and starts the destination QEMU with the explicit
interrupt controller (like -machine pseries,intrc=xive).

Hacking QEMU to do all of this is still in a distant TODO...


> 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



-- 
Alexey