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). 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. > > >>> 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. > > > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature