On 09/22/2017 12:33 PM, David Gibson wrote: > On Thu, Sep 21, 2017 at 04:18:33PM +0200, Cédric Le Goater wrote: >> On 09/21/2017 03:25 AM, David Gibson wrote: >>> On Wed, Sep 20, 2017 at 02:33:37PM +0200, Cédric Le Goater wrote: >>>> On 09/19/2017 10:46 AM, David Gibson wrote: >>>>> On Tue, Sep 19, 2017 at 06:20:20PM +1000, David Gibson wrote: >>>>>> On Mon, Sep 11, 2017 at 07:12:14PM +0200, Cédric Le Goater wrote: >>>>>>> On a POWER9 sPAPR machine, the Client Architecture Support (CAS) >>>>>>> negotiation process determines whether the guest operates with an >>>>>>> interrupt controller using the XICS legacy model, as found on POWER8, >>>>>>> or in XIVE exploitation mode, the newer POWER9 interrupt model. This >>>>>>> patchset is a proposal to add XIVE support in POWER9 sPAPR machine. >>>>>>> >>>>>>> Follows a model for the XIVE interrupt controller and support for the >>>>>>> Hypervisor's calls which are used to configure the interrupt sources >>>>>>> and the event/notification queues of the guest. The last patch >>>>>>> integrates XIVE in the sPAPR machine. >>>>>>> >>>>>>> Code is here: >>>>>> >>>>>> >>>>>> An overall comment: >>>>>> >>>>>> I note in several replies here that I think the way XICS objects are >>>>>> re-used for XIVE is really ugly, and I think it will make future >>>>>> maintenance pretty painful. >>>> >>>> I agree. That was one way to identify what we need for migration >>>> compatibility and CAS reset. >>>> >>>>>> I'm thinking maybe trying to support the CAS negotiation of interrupt >>>>>> controller from day 1 is warping the design. A better approach might >>>>>> be first to implement XIVE only when given a specific machine option - >>>>>> guest gets one or the other and can't negotiate. >>>> >>>> ok. >>>> >>>> CAS is not the most complex problem, we mostly need to share >>>> the ICSIRQState array and the source offset. migration from older >>>> machine is a problem. >>> >>> Uh.. what? Migration from an older machine isn't a thing. We can >>> migrate from an older qemu, but the machine type (and version) has to >>> be identical at each end. That's *why* we keep around the older >>> machine types on newer qemus. >> >> yes. I am just wondering how I am going to handle a xics-only >> machine migrating to a xics/xive machine. > > Won't ever happen. Older machine types will always be xics, newer > machine type will always be xive (at least with POWER9). > >> The xive machine option we are talking about will activate >> the xive interrupt mode and instantiate the objects behind it. >> So when we migrate from an older machine we will need to start >> the target machine with xive=off. I guess that is OK. > > Again, we *don't* migrate from an older machine. Ever. We only ever > migrate from an older qemu version to a newer qemu using the older > machine type.
Sorry I was talking about QEMU version, and not machine version. I still have to look at how both machines will cohabitate in the newer QEMU. Thanks, C. >> >> Thanks for the insights and the time to review the code, >> >> C. >> >>>> We are doomed to keep the existing XICS >>>> framework available. >>>> >>>>>> That should allow a more natural XIVE design to emerge, *then* we can >>>>>> look at what's necessary to make boot-time negotiation possible. >>>>> >>>>> Actually, it just occurred to me that we might be making life hard for >>>>> ourselves by trying to actually switch between full XICS and XIVE >>>>> models. Coudln't we have new machine types always construct the XIVE >>>>> infrastructure, >>>> >>>> yes. >>>> >>>>> but then implement the XICS RTAS and hcalls in terms of the XIVE virtual >>>>> hardware. >>>> >>>> ok but migration will not be supported. >>> >>> Right, this would only be for newer machine types, and you can never >>> migrate between different machine types. >>> >>>>> Since something more or less equivalent >>>>> has already been done in both OPAL and the host kernel, I'm guessing >>>>> this shouldn't be too hard at this point. >>>> >>>> Indeed that is how it is working currently on P9 kvm guests. hcalls are >>>> implemented on top of XIVE native. >>>> >>>> Thanks, >>>> >>>> >>>> C. >>>> >>> >> >
