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.
> 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
signature.asc
Description: PGP signature
