Re: [Qemu-ppc] [PATCH v3] ppc: introduce CPUPPCState::cpu_dt_id

[Scott Wood]

On Tue, 2013-11-05 at 07:00 +0100, Alexander Graf wrote:
> 
> Am 05.11.2013 um 02:48 schrieb Scott Wood <address@hidden>:
> 
> > On Tue, 2013-11-05 at 12:26 +1100, Alexey Kardashevskiy wrote:
> >> On 11/05/2013 06:42 AM, Scott Wood wrote:
> >>> On Mon, 2013-11-04 at 10:41 +0100, Alexander Graf wrote:
> >>>> What we really have are 3 semantically separate entities:
> >>>> 
> >>>>  * QEMU internal cpu id
> >>>>  * KVM internal cpu id
> >>>>  * DT exposed cpu id
> >>>> 
> >>>> As you have noted, it's a good idea to keep the QEMU internal cpu id
> >>>> linear, thus completely separate from the others. The DT exposed cpu id
> >>>> should be 100% local to hw/ppc/spapr*.c. I don't think any code outside
> >>>> of the DT generation and anything that accesses the "Virtual Processor
> >>>> Number" in sPAPR needs to care about the DT cpu id. All that code is
> >>>> 100% KVM agnostic.
> >>> 
> >>> This patch isn't just for sPAPR...  On e500 the DT cpu id is supposed to
> >>> match the MPIC cpu id.
> >> 
> >> 
> >> At least is my patch correct for e500?
> > 
> > I think so.
> > 
> >> I do not really know what is the difference between e500 and spapr in this 
> >> part.
> > 
> > e500 does not have sPAPR, and if the DT ID is "100% local to
> > hw/ppc/spapr*.c" then the MPIC code will have a problem.
> > 
> > Currently we don't support smt on e500 in QEMU, but e6500 (an
> > e500-derivative) does have smt, so it could happen in the future.
> 
> Sure, at that point we add logic that syncs the kvm and dt ids to whatever 
> the kernel expects from the e500 machine file.
> 
> The current logic that says "every Nth vcpu id is a core, the ones in
> between are threads" is fairly implementation specific to the spapr hv
> code, no?

It's the same on e6500, though I agree that in theory it should not be
generic code specifying the scheme.  My point relates to the consumer of
this information -- "device tree CPU ID" is a concept that makes sense
outside of sPAPR.

Note that the connection between the interrupt controller and the CPU
reg is an ePAPR requirement, not just a coincidence, or something we
only do on MPIC.  PIR is also supposed to match the device tree CPU ID
-- especially under KVM, where PIR is not modifiable by the guest, in
the absence of a device tree binding specifically for PIR which we do
not have.

-Scott