Hi Markus,
Just a kindly ping. Hopefully we can continue this discussion when
you're free.
Regards,
Zhao
On Fri, Aug 02, 2024 at 03:58:02PM +0800, Zhao Liu wrote:
> Date: Fri, 2 Aug 2024 15:58:02 +0800
> From: Zhao Liu <zhao1....@intel.com>
> Subject: Re: [PATCH 8/8] qemu-options: Add the description of smp-cache
> object
>
> On Thu, Aug 01, 2024 at 01:28:27PM +0200, Markus Armbruster wrote:
> > Date: Thu, 01 Aug 2024 13:28:27 +0200
> > From: Markus Armbruster <arm...@redhat.com>
> > Subject: Re: [PATCH 8/8] qemu-options: Add the description of smp-cache
> > object
> >
> > Zhao Liu <zhao1....@intel.com> writes:
> >
> > > On Thu, Jul 25, 2024 at 11:07:12AM +0200, Markus Armbruster wrote:
> > >> Date: Thu, 25 Jul 2024 11:07:12 +0200
> > >> From: Markus Armbruster <arm...@redhat.com>
> > >> Subject: Re: [PATCH 8/8] qemu-options: Add the description of smp-cache
> > >> object
> > >>
> > >> Zhao Liu <zhao1....@intel.com> writes:
> > >>
> > >> > Hi Markus and Daniel,
> > >> >
> > >> > I have the questions about the -object per cache implementation:
> > >> >
> > >> > On Wed, Jul 24, 2024 at 02:39:29PM +0200, Markus Armbruster wrote:
> > >> >> Date: Wed, 24 Jul 2024 14:39:29 +0200
> > >> >> From: Markus Armbruster <arm...@redhat.com>
> > >> >> Subject: Re: [PATCH 8/8] qemu-options: Add the description of
> > >> >> smp-cache
> > >> >> object
> > >> >>
> > >> >> Zhao Liu <zhao1....@intel.com> writes:
> > >> >>
> > >> >> > Hi Markus,
> > >> >> >
> > >> >> > On Mon, Jul 22, 2024 at 03:37:43PM +0200, Markus Armbruster wrote:
> > >> >> >> Date: Mon, 22 Jul 2024 15:37:43 +0200
> > >> >> >> From: Markus Armbruster <arm...@redhat.com>
> > >> >> >> Subject: Re: [PATCH 8/8] qemu-options: Add the description of
> > >> >> >> smp-cache
> > >> >> >> object
> > >> >> >>
> > >> >> >> Zhao Liu <zhao1....@intel.com> writes:
> > >> >> >>
> > >> >> >> > Signed-off-by: Zhao Liu <zhao1....@intel.com>
> > >> >> >>
> > >> >> >> This patch is just documentation. The code got added in some
> > >> >> >> previous
> > >> >> >> patch. Would it make sense to squash this patch into that previous
> > >> >> >> patch?
> > >> >> >
> > >> >> > OK, I'll merge them.
> > >> >> >
> > >> >> >> > ---
> > >> >> >> > Changes since RFC v2:
> > >> >> >> > * Rewrote the document of smp-cache object.
> > >> >> >> >
> > >> >> >> > Changes since RFC v1:
> > >> >> >> > * Use "*_cache=topo_level" as -smp example as the original
> > >> >> >> > "level"
> > >> >> >> > term for a cache has a totally different meaning. (Jonathan)
> > >> >> >> > ---
> > >> >> >> > qemu-options.hx | 58
> > >> >> >> > +++++++++++++++++++++++++++++++++++++++++++++++++
> > >> >> >> > 1 file changed, 58 insertions(+)
> > >> >> >> >
> > >> >> >> > diff --git a/qemu-options.hx b/qemu-options.hx
> > >> >> >> > index 8ca7f34ef0c8..4b84f4508a6e 100644
> > >> >> >> > --- a/qemu-options.hx
> > >> >> >> > +++ b/qemu-options.hx
> > >> >> >> > @@ -159,6 +159,15 @@ SRST
> > >> >> >> > ::
> > >> >> >> >
> > >> >> >> > -machine
> > >> >> >> > cxl-fmw.0.targets.0=cxl.0,cxl-fmw.0.targets.1=cxl.1,cxl-fmw.0.size=128G,cxl-fmw.0.interleave-granularity=512
> > >> >> >> > +
> > >> >> >> > + ``smp-cache='id'``
> > >> >> >> > + Allows to configure cache property (now only the cache
> > >> >> >> > topology level).
> > >> >> >> > +
> > >> >> >> > + For example:
> > >> >> >> > + ::
> > >> >> >> > +
> > >> >> >> > + -object
> > >> >> >> > '{"qom-type":"smp-cache","id":"cache","caches":[{"name":"l1d","topo":"core"},{"name":"l1i","topo":"core"},{"name":"l2","topo":"module"},{"name":"l3","topo":"die"}]}'
> > >> >> >> > + -machine smp-cache=cache
> > >> >> >> > ERST
> > >> >> >> >
> > >> >> >> > DEF("M", HAS_ARG, QEMU_OPTION_M,
> > >> >> >> > @@ -5871,6 +5880,55 @@ SRST
> > >> >> >> > ::
> > >> >> >> >
> > >> >> >> > (qemu) qom-set /objects/iothread1 poll-max-ns 100000
> > >> >> >> > +
> > >> >> >> > + ``-object
> > >> >> >> > '{"qom-type":"smp-cache","id":id,"caches":[{"name":cache_name,"topo":cache_topo}]}'``
> > >> >> >> > + Create an smp-cache object that configures machine's
> > >> >> >> > cache
> > >> >> >> > + property. Currently, cache property only include cache
> > >> >> >> > topology
> > >> >> >> > + level.
> > >> >> >> > +
> > >> >> >> > + This option must be written in JSON format to support
> > >> >> >> > JSON list.
> > >> >> >>
> > >> >> >> Why?
> > >> >> >
> > >> >> > I'm not familiar with this, so I hope you could educate me if I'm
> > >> >> > wrong.
> > >> >> >
> > >> >> > All I know so far is for -object that defining a list can only be
> > >> >> > done in
> > >> >> > JSON format and not with a numeric index like a keyval based
> > >> >> > option, like:
> > >> >> >
> > >> >> > -object smp-cache,id=cache0,caches.0.name=l1i,caches.0.topo=core:
> > >> >> > Parameter 'caches' is missing
> > >> >> >
> > >> >> > the above doesn't work.
> > >> >> >
> > >> >> > Is there any other way to specify a list in command line?
> > >> >>
> > >> >> The command line is a big, sprawling mess :)
> > >> >>
> > >> >> -object supports either a JSON or a QemuOpts argument. *Not* keyval!
> > >> >>
> > >> >> Both QemuOpts and keyval parse something like KEY=VALUE,... Keyval
> > >> >> supports arrays and objects via dotted keys. QemuOpts doesn't
> > >> >> natively
> > >> >> support arrays and objects, but its users can hack around that
> > >> >> limitation in various ways. -object doesn't. So you're right, it's
> > >> >> JSON or bust here.
> > >> >>
> > >> >> However, if we used one object per cache instead, we could get
> > >> >> something
> > >> >> like
> > >> >>
> > >> >> -object smp-cache,name=l1d,...
> > >> >> -object smp-cache,name=l1u,...
> > >> >> -object smp-cache,name=l2,...
> > >> >> ...
> > >> >
> > >> > Current, I use -object to create a smp_cache object, and link it to
> > >> > MachineState by -machine,smp-cache=obj_id.
> > >> >
> > >> > Then for the objects per cache, how could I link them to machine?
> > >> >
> > >> > Is it possible that I create something static in smp_cache.c and expose
> > >> > all the cache information to machine through some interface?
> > >>
> > >> Good questions. However, before we head deeper into the weeds here, I
> > >> feel we should discuss the things below. And before we do that, I need
> > >> a clear understanding of the use case. Elsewhere in this thread, I just
> > >> described the use case as I understand it. Please reply there. I'll
> > >> then come back to this message.
> > >>
> > >> [...]
> > >
> > > Jonathan and I provided different use cases for x86 and Arm. Could we
> > > come back here to continue the discussion? :)
> >
> > Can you provide a brief summary of the design alternatives that have
> > been proposed so far? Because I've lost track.
>
> No problem!
>
> Currently, we have the following options:
>
> * 1st: The first one is just to configure cache topology with several
> options in -smp:
>
> -smp l1i-cache-topo=core,l1d-cache-topo-core
>
> This one lacks scalability to support the cache size that ARM will
> need in the future.
>
>
> * 2nd: The cache list object in -smp.
>
> The idea was to use JSON to configure the cache list. However, the
> underlying implementation of -smp at the moment is keyval parsing,
> which is not compatible with JSON.
>
> If we can not insist on JSON format, then cache lists can also be
> implemented in the following way:
>
> -smp caches.0.name=l1i,caches.0.topo=core,\
> caches.1.name=l1d,caches.1.topo=core
>
>
> * 3rd: The cache list object linked in -machine.
>
> Considering that -object is JSON-compatible so that defining lists via
> JSON is more friendly, I implemented the caches list via -object and
> linked it to MachineState:
>
> -object
> '{"qom-type":"smp-cache","id":"obj","caches":[{"name":"l1d","topo":"core"},{"name":"l1i","topo":"core"}]}'
> -machine smp-caches=obj
>
>
> * 4th: The per cache object without any list:
>
> -object smp-cache,id=cache0,name=l1i,topo=core \
> -object smp-cache,id=cache1,name=l1d,topo=core
>
> This proposal is clearer, but there are a few opens:
> - I plan to push qom-topo forward, which would abstract CPU related
> topology levels and cache to "device" instead of object. Is there a
> conflict here?
>
> - Multiple cache objects can't be linked to the machine on the command
> line, so I maintain a static cache list in smp_cache.c and expose
> the cache information to the machine through some interface. is this
> way acceptable?
>
>
> In summary, the 4th proposal was the most up in the air, as it looked to
> be conflict with the hybrid topology I wanted to do (and while hybrid
> topology may not be accepted by the community either, I thought it would
> be best for the two work to be in the same direction).
>
> The difference between 2nd and 3rd is about the JSON requirement, if JSON
> is mandatory for now then it's 3rd, if it's not mandatory (or accept to
> make -machine/-smp support JSON in the future), 2nd looks cleaner, which
> puts the caches list in -smp.
>
> Regards,
> Zhao
>
>
>
