Re: [Qemu-devel] [Qemu-ppc] [PATCH 41/77] ppc/pnv: Add LPC controller and hook it up with a UART and RTC

[Benjamin Herrenschmidt]

On Thu, 2015-12-03 at 12:45 +1100, David Gibson wrote:
> 
> There are several different cases here and I'm not sure which you're
> thinking about.
> 
> 1) Guest has different number of threads-per-core than the host
> 
> This one is just fine - PAPR defines how the guest should get the
> number of threads from the device tree, and qemu sets that correctly.
> 
> 2) Guest threads-per-core not a power of two
> 
> The PAPR thread mechanism allows this to be communicated to the guest,
> and I don't know if PAPR explicitly permits or prohibitis this
> situation.  Guests could get confused by it, although that's arguably
> a guest bug.

Linux only supports powers of 2

 .../...

> > For now, if possible, I'd suggest implementing -nodefaults with no defaults
> > whatsoever and create a config somewhere in the qemu tree to pass it via
> > -readconfig to get reasonably configured machine so people will know what is
> > expected to work but there will still be possibility for experiments (do not
> > we secretly hope that other vendors will start designing/manufacturing their
> > ppc64 chips?). It could be a config file per an actual POWER8 chip (we have
> > two already).
> 
> I can see some benefit to that approach, but it does stray away from
> current qemu practice (in general, not just compared to spapr).
> Hmm.. not sure.

I don't see an urgent need. We can do that in a separate series if we
want to. As I said in another email, I don't want powernv to be "set in
stone" in term of ABIs & migration for a while, so we have latitude to
play with the model for a while before we lock things down. At least
until after P9.

> What I do think would be a good idea is to represent a POWER8 "chip"
> as a instantiable qdev device, which will create the scoms and PHBs
> under itself as per the hardware.  We can add device properties as
> needed to make that construction more flexible.

It would also instanciate the CPUs. I want to change that in the
current model, just haven't got to it yet.

> We probably don't want to link the number of CPUs to the chip qdevs,
> partly because that doesn't really fit the qemu model, but also
> because we'll probably want some extra flexibility.  e.g. making a UP
> system for experimentation, even though a single chip would have
> multiple cores (IIUC) - SMP TCG is super slow, so we probably want that.

We want to eventually represent the EX units properly on XSCOM (the
cores). So we will need that tie between chip and CPU. But we don't
have to mark all cores in a chip as "enabled". It's ok to have chips
with only one good core for example.

Cheers,
Ben.