On 04/12/2018 07:10 AM, David Gibson wrote: > On Wed, Jan 17, 2018 at 10:18:43AM +0100, Cédric Le Goater wrote: >>>>> 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. > > I think for our first draft we should have XIVE and XICS based > platforms as separate machine types (or a machine option, I guess).
OK. This is my current choice for KVM. Emulated mode is rather simple to handle, and this is why I have kept the reset after CAS if there is a change in the interrupt mode. > We do want to allow this to be autonegotiated, but I feel like > emphasising that at the beginning is causing unnatural design > decisions in the XIVE model itself. Yes. This is mostly a KVM problem which also has impacts on XICS of course ... C. >> >>>>> 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. >>> >> >
