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

[Alexey Kardashevskiy]

On 12/02/2015 04:29 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2015-12-02 at 13:24 +1100, Alexey Kardashevskiy wrote:
> > > But on the whole I agree with you, since the LPC is part of the P8
> > > chip, I think it makes sense to include it even with -nodefaults.
> >
> > POWER8 chips all have 8 threads per core but we do not always assume -smt
> > ...,threads=8, how are LPC or PHB different?
>
> First, for pseries which is paravirtualized it's a different can of
> worms completely. For powernv, we *should* represent all 8 threads,
> we just can't yet due to TCG limitations.

Out of curiosity - for pseries we should not? I know it works with various 
numbers of threads but is not that because we also control guest linux 
kernel and, for example, the Other OS (AIX) might be upset on 
non-multiply-of-2 number of threads?


> > PHB is more interesting - how is the user supposed to add more?
>
> That's an open question. Since we model a real P8 chip we can only
> model the PHBs as they exist on it, which is up to 3 per chip at
> very specific XSCOM addresses. We could try to model some non-existing
> P8 chip with more but bad things will happen when the FW try to assign
> interrupt numbers for example.
>
> We simulate a machine that has been primed by HostBoot before OPAL
> starts. So we rely on what the device-tree tells us of what PHB were
> enabled but appart from that, we have to stick to the limitations.
>
> > And there always will be the default one
> > which properties are set in a separate way (via -global, not -device). I
> > found it sometime really annoying to debug the existing pseries which
> > always adds a default PHB (I know, this was to make libvirt happy but this
> > is not the case here).
> >
> > Out of curiosity - if we have 2 chips, will the system work if the second
> > chip does not get any LPC or PHB attached?
>
> This is something I need to look into, there's a lot of work needed to
> properly model "chips" that I haven't done yet, but what is there is
> sufficient for a lot of usages already.

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).


--
Alexey