Re: [Qemu-devel] [PATCH v3 06/35] spapr/xive: introduce a XIVE interrupt presenter model

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 1645 bytes --]

On Wed, May 02, 2018 at 09:39:44AM +0200, Cédric Le Goater wrote:
> >>  
> >> +static XiveNVT *spapr_xive_get_nvt(XiveFabric *xf, uint32_t server)
> >> +{
> >> +    PowerPCCPU *cpu = spapr_find_cpu(server);
> >> +
> >> +    return cpu ? XIVE_NVT(cpu->intc) : NULL;
> >> +}
> > 
> > So this is a bit of a tangent, but I've been thinking of implementing
> > a scheme where there's an opaque pointer in the cpu structure for the
> > use of the machine.  I'm planning for that to replace the intc pointer
> > (which isn't really used directly by the cpu). That would allow us to
> > have spapr put a structure there and have both xics and xive pointers
> > which could be useful later on.
> 
> Here is a quick try of the idea. Tested on pnv and spapr machines.
> I lacked inspiration on the name so I called the object
> {Machine}Link.

This is a bit overkill compared to what I had in mind.  I don't think
the thing we're pointing to has to be a fully realized QOM object.  I
was just going to replace the Object * with a void *, that it's up to
the machine to interpret.

I'm also wondering about restricting this idea to vhyp platforms.  The
idea is that for physical-esque machines the cpu really does (or
should) know how things are connected to it.  It's the abstraction of
the paravirt platform that makes it fuzzy.  In which case I'd see it
as the "opaque" pointer that goes along with the vhyp function
pointers.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]