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

[Cédric Le Goater]

On 05/03/2018 07:43 AM, David Gibson wrote:
> 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. 

Yes, it is quite a bit of code for a simple struct.

> I was just going to replace the Object * with a void *, that it's up to
> the machine to interpret.

So the machine would just g_malloc0 a custom struct for each CPU, filling
it out depending on the configuration/needs ? 
 
> I'm also wondering about restricting this idea to vhyp platforms.  

OK. 

> The idea is that for physical-esque machines the cpu really does (or
> should) know how things are connected to it.  

yes. P9 does not have a XICS interrupt controller on PowerNV.

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

I will take a look for the intc pointer as xive needs an extra one.

C.