[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
From: |
Cédric Le Goater |
Subject: |
Re: [Qemu-ppc] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller |
Date: |
Wed, 17 Jan 2018 10:18:43 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
>>> Also, have we decided how the process of switching between XICS and
>>> XIVE will work vs. CAS ?
>>
>> That's how it is described in the architecture. The current choice is
>> to create both XICS and XIVE objects and choose at CAS which one to
>> use. It relies today on the capability of the pseries machine to
>> allocate IRQ numbers for both interrupt controller backends. These
>> patches have been merged in QEMU.
>>
>> A change of interrupt mode results in a reset. The device tree is
>> populated accordingly and the ICPs are switched for the model in
>> use.
>
> For KVM we need to only instanciate one of them though.
Hmm,
How would we handle a guest rebooting on a kernel without XIVE support ?
Are you suggesting to create the XICS or XIVE device in the CAS negotiation
process ? So, the machine would not have any interrupt controller before
CAS. That seems really late to me. grub uses the console for instance.
I think it should prepare for both options, start in XIVE legacy mode,
which is XICS, then possibly switch to XIVE exploitation mode.
>>> And how that will interact with KVM ?
>>
>> I expect we will do the same, which is to create two KVM devices to
>> be able to handle both interrupt controller backends depending on the
>> mode negotiated by the guest.
>
> That will be an ungodly mess, I'd rather we only instanciate the right
> one.
It's rather transparent currently in the emulated version. There are two
sets of objects in QEMU, switching is done in CAS. KVM support should not
change anything in that area.
I expect the 'xive-kvm' object to get/set states for migration, just like
for XICS and to setup the ESB+TIMA memory regions, which is new.
C.
>>> I was
>>> thinking the kernel would implement a different KVM device type, ie
>>> the "emulated XICS" would remain KVM_DEV_TYPE_XICS and XIVE would be
>>> KVM_DEV_TYPE_XIVE.
>>
>> yes. it makes sense. The new device will have a lot in common with the
>> KVM_DEV_TYPE_XICS using kvm_xive_ops.
>
> Ben.
>
- Re: [Qemu-ppc] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller,
Cédric Le Goater <=