Re: [PATCH 8/8] qemu-options: Add the description of smp-cache object

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

Just picking out one element.

> 
> > If I forcibly ignore all the considerations related to concrete syntax
> > in your message, a structure seems to emerge: there's a set of caches
> > identified by name (l1i, l1d, ...), and for each cache, we have a number
> > of configurable properties (topology level, ...).  Makes sense?  
> 
> Yes, you're right!
> 
> > What else will you need to configure in the future?  
> 
> Maybe cache size, as Jonathan mentioned for Arm side.

Everything that ends up in ACPI PPTT either via the relationships between
the various structures, or as data in the cache entries.
(some of this also goes in system registers, but this is a superset of
what is needed to generate PPTT for a guest on a KVM system by
reading a bunch of sysfs files on the host).

The topology stuff is about relationships (pointers effectively) in that table
the other is probably all the fields in "Cache Type Structure - Type 1"
- Size
- Number of sets
- Associativity
- Line size
- Allocation type (read allocate; write allocate; read and write alloc)
- (cache type - already encoded via l1i, l1d etc)
- Write Policy - (write back, write through)

> 
> > By the way, extending -machine to support JSON looks feasible to me at a
> > glance.  
>  
> Thanks again! Then I made it clear that it would be most appropriate to
> place the cache array in -machine, i.e., it's extensible and consistent
> with the design of the rest of the machine's properties, as well as
> consistent with my long-term needs.
> 
> Later on, if -machine is able to support JSON, it will also benefit from
> it. If I have time, I will also think about how -machine can support
> JSON.
> 
> Regards,
> Zhao
> 
>