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.
