[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 6/7] target/ppc: Replace intc pointer with a gen

From: David Gibson
Subject: Re: [Qemu-devel] [PATCH 6/7] target/ppc: Replace intc pointer with a general machine_data pointer
Date: Wed, 13 Jun 2018 19:45:54 +1000
User-agent: Mutt/1.10.0 (2018-05-17)

On Wed, Jun 13, 2018 at 10:46:02AM +0200, Cédric Le Goater wrote:
> On 06/13/2018 08:57 AM, David Gibson wrote:
> > PowerPCCPU contains an (Object *)intc used to point to the cpu's interrupt
> > controller. Or more precisely to the "presentation" component of the
> > interrupt controller relevant to this cpu.
> yes and that made sense in terms of modeling because you actually have a 
> set of wires between the presenter and the cores of a system.
> > Really, this field is machine specific.  The machines which use it can
> > point it to different types of object depending on their needs, and most
> > machines don't use it at all (since they have older style PICs which don't
> > have per-cpu presentation components).
> > 
> > There's also other information that's per-cpu, but platform/machine
> > specific.  So replace the intc pointer with a (void *)machine_data which
> > can be managed as the machine type likes to conveniently store per cpu
> > information.
> ah. so you have something else the store in the machine_data. 
> If you were defining a type, we would have some more checks when 
> casting the machine_data field. We also could parent the object 
> to the CPU also. This is minor.

My intention is that machine_data be a "passive" structure, not a QOM
object.  Lifetime and type management are all up to the machine.

> The change should be compatible with the XIVE change which need 
> to allocate a different type of presenter. So, sPAPRCPUState and 
> PnvCPUState would look like :
>       typedef struct sPAPRCPUState {
>           ICPState *icp;
>           XiveTCTX *tctx;
>       } sPAPRCPUState;


> and the call to ipc_create() will move in an operation of the 
> sPAPR IRQ backend, if that exists oneday, and in an operation of 
> the PnvChip to handle the differences in the interrupt controller
> in use by the machine. 
> So no big difference, but the cpu machine_data won't be populated
> from the core but from the machine. I hope this is compatible
> with the next changes.

intc was already populated from the machine.

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

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]