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

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