[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 6/7] target/ppc: Replace intc pointer with a gener
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [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;
Exactly.
> 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_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
- [Qemu-ppc] [PATCH 5/7] pnv: Add cpu unrealize path, (continued)