Re: [Qemu-ppc] Cache sizes and device tree

[Alexander Graf]

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.

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

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


Alex