[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] Cache sizes and device tree
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] Cache sizes and device tree |
Date: |
Tue, 20 Nov 2012 09:05:32 +1100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Nov 19, 2012 at 12:32:51PM +0100, Alexander Graf wrote:
>
> On 16.11.2012, at 04:36, David Gibson wrote:
>
> > Hi Alex,
> >
> > At present, pseries doesn't set the i-cache-size and d-cache-size
> > properties on the device tree CPU nodes. That's a bit of a pain,
> > because it means the guest kernel then doesn't provide some files in
> > /sys and that means that lscpu bombs out with an error.
> >
> > So the question is what should we put in there. For KVM it's
> > straightforward enough for us to find the host L1 cache sizes and put
> > those in the guest device tree. However to make it work for full emu
> > as well, we'll need to add this cache size information to the qemu cpu
> > table somewhere.
>
> Well, cache size should be modeled pretty much the same way as cache
> line size, right? Today, for cache line size, we just set the
> respective values in the cpu init functions.
>
> > In practice, I think we need a way to add it incrementally - since I
> > really don't want to have to look up and confirm the L1 cache size for
> > every one of the hundreds of supported CPU models in order to make an
> > initial patch.
>
> Sure. Just add a check if (env->cache_size_l1) and only set the dt
> property in that case ;). For KVM. override the env value similar to
> how we do it for the timebase.
Erm.. I'm not sure which timebase override you're referring to.
> > I'm thinking it should probably go into ppc_def_t. That will need a
> > new DEF macro which includes the cache sizes, and then there will be a
> > somewhat ugly but manageable transition to the new macro as we add
> > cache sizes to various CPUs. But then I'm not entirely sure how to
> > get to the information when we're building the devtree, since there
> > isn't actually an obvious link from the CPUPPCState to the ppc_def_t
> > it was created from.
>
> I think just shoving it into env should be enough, no? Do we have
> any cache information that goes beyond vcpu level, so that we can
> not populate it in env?
Well.. I was thinking ppc_def_t because there's an obvious place to
retrieve the host value in the kvm case - kvmppc_host_cpu_def(). It's
not so clear to me where we would do that if it's only in env.
> > Any thoughts on how to handle this?
>
> If you're really up for refactoring fun, it would make sense for a
> lot of variables to go out of env and into statically defined CPU
> definitions. But no code really does that today, so I don't see why
> this particular use case would require it :)
--
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