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