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

["Cédric Le Goater" <clg@kaod.org>]

On 02/11/2018 11:55 PM, 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 ?
> 
> Otherwise, we have indeed no much choice but the horrible wart of
> creating both interrupt controllers with only one "active".

Well, both QEMU model objects would be created, yes, but one only KVM 
associated device. It's a bit ugly from a QEMU point of view because  
the KVM initialization is deferred at reset but, in the pratice, it 
results in a couple of calls to : 

  - disconnect the VCPU from the KVM interrupt device
  - destroy the previous KVM interrupt device (new ioctl)
  - create the new KVM interrupt device
  - reconnect the VCPU to the KVM interrupt device

I don't think it will be a major problem.

What I am unease with currently, is how to share the same XIVE objects 
when under KVM and when not. The only difference is in the nature of
the MMIO region and the qemu_irq handler. Work in progress.

And we have four interrupt modes to support : XICS-KVM, XICS, XIVE-KVM, 
XIVE.    

Thanks,

C. 
 

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