[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
Wed, 17 Jan 2018 10:18:43 +0100
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
> For KVM we need to only instanciate one of them though.
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
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.
>>> 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
>> yes. it makes sense. The new device will have a lot in common with the
>> KVM_DEV_TYPE_XICS using kvm_xive_ops.
- Re: [Qemu-ppc] [PATCH v2 02/19] spapr: introduce a skeleton for the XIVE interrupt controller,
Cédric Le Goater <=