qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-ppc] [PATCH 41/77] ppc/pnv: Add LPC controller an


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 41/77] ppc/pnv: Add LPC controller and hook it up with a UART and RTC
Date: Fri, 04 Dec 2015 09:54:28 +1100

On Thu, 2015-12-03 at 12:04 +1100, Alexey Kardashevskiy wrote:
> 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? 

Not that we should not, more like, it makes sense to offer whatever
choice, it would be indeed better to have the ability to support them
however.

> 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?

Quite possibly. I have some plans to add threads support, just haven't
got to it yet :-)
> 
> > > 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).

There could be, but we'd need ways to specify a bunch of things, it's
not that trivial. IE, the xscom addresses of the 3 ranges for each PHB
for example etc.. For now let's keep things simple.

I also am in no hurry to support migration with powernv, so we have
quite a bit of flexibility to change things.

Cheers,
Ben.




reply via email to

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