public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Zhao Liu <zhao1.liu@intel.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Eric Blake" <eblake@redhat.com>,
	"Michael Roth" <michael.roth@amd.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcelo Tosatti" <mtosatti@redhat.com>,
	"Shaoqin Huang" <shahuang@redhat.com>,
	"Eric Auger" <eauger@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Sebastian Ott" <sebott@redhat.com>,
	"Gavin Shan" <gshan@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org, qemu-arm@nongnu.org,
	"Dapeng Mi" <dapeng1.mi@intel.com>, "Yi Lai" <yi1.lai@intel.com>,
	"Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [RFC v2 1/5] qapi/qom: Introduce kvm-pmu-filter object
Date: Tue, 1 Apr 2025 15:47:36 +0800	[thread overview]
Message-ID: <Z+uaGHiOkFJd6TAO@intel.com> (raw)
In-Reply-To: <87v7tlhpqj.fsf@pond.sub.org>

Hi Mrkus,

I'm really sorry I completely missed your reply (and your patient
advice). It wasn't until I looked back at the lore archives that I
realized my mistake. Thinking it over again, I see that your reply,
which I missed, really helped clear up my confusion:

On Fri, Feb 07, 2025 at 02:02:44PM +0100, Markus Armbruster wrote:
> Date: Fri, 07 Feb 2025 14:02:44 +0100
> From: Markus Armbruster <armbru@redhat.com>
> Subject: Re: [RFC v2 1/5] qapi/qom: Introduce kvm-pmu-filter object
> 
> Zhao Liu <zhao1.liu@intel.com> writes:
> 
> >> Let's ignore how to place it for now, and focus on where we would *like*
> >> to place it.
> >> 
> >> Is it related to anything other than ObjectType / ObjectOptions in the
> >> QMP reference manual?
> >
> > Yes!
> 
> Now I'm confused :)
> 
> It is related to ObjectType / ObjectType.
> 
> Is it related to anything else in the QMP reference manual, and if yes,
> to what exactly is it related?

I misunderstood your point. The PMU stuff and the QAPI definitions for
ObjectType/ObjectOptions are not related. They should belong to separate
categories or sections.

> >> I guess qapi/kvm.json is for KVM-specific stuff in general, not just the
> >> KVM PMU filter.  Should we have a section for accelerator-specific
> >> stuff, with subsections for the various accelerators?
> >> 
> >> [...]
> >
> > If we consider the accelerator from a top-down perspective, I understand
> > that we need to add accelerator.json, kvm.json, and kvm-pmu-filter.json.
> >
> > The first two files are just to include subsections without any additional
> > content. Is this overkill? Could we just add a single kvm-pmu-filter.json
> > (I also considered this name, thinking that kvm might need to add more
> > things in the future)?
> >
> > Of course, I lack experience with the file organization here. If you think
> > the three-level sections (accelerator.json, kvm.json, and kvm-pmu-filter.json)
> > is necessary, I am happy to try this way. :-)
> 
> We don't have to create files just to get a desired section structure.
> 
> I'll show you how in a jiffie, but before I do that, let me stress: we
> should figure out what we want *first*, and only then how to get it.
> So, what section structure would make the most sense for the QMP
> reference manual?

Thank you for your patience. I have revisited and carefully considered
the "QEMU QMP Reference Manual," especially from a reader's perspective.
Indeed, I agree that, as you mentioned, a three-level directory
(accelerator - kvm - kvm stuff) is more readable and easier to maintain.

For this question "what we want *first*, and only then how to get it", I
think my thought is:

First, the structure should be considered, and then the specific content
can be added. Once the structure is clearly defined, categorizing items
into their appropriate places becomes a natural process...

Then for this question "what section structure would make the most sense
for the QMP reference manual?", I understand that a top-down, clearly
defined hierarchical directory makes the most sense, allowing readers to
follow the structure to find what they want. Directly adding
kvm-pmu-filter.json or kvm.json would disrupt the entire structure, because
KVM is just one of the accelerators supported by QEMU. Using "accelerator"
as the entry point for the documentation, similar to the "accel" directory
in QEMU's source code, would make indexing more convenient.

> A few hints on how...
> 
> Consider how qapi/block.json includes qapi/block-core.json:
> 
>     ##
>     # = Block devices
>     ##
> 
>     { 'include': 'block-core.json' }
> 
>     ##
>     # == Additional block stuff (VM related)
>     ##
> 
> block-core.json starts with
> 
>     ##
>     # == Block core (VM unrelated)
>     ##
> 
> Together, this produces this section structure
> 
>     = Block devices
>     == 
>     ##
> 
> Together, this produces this section structure
> 
>     = Block devices
>     == Block core (VM unrelated)
>     == Additional block stuff (VM related)
> 
> Note that qapi/block-core.json isn't included anywhere else.
> qapi/qapi-schema.json advises:
> 
>     # Documentation generated with qapi-gen.py is in source order, with
>     # included sub-schemas inserted at the first include directive
>     # (subsequent include directives have no effect).  To get a sane and
>     # stable order, it's best to include each sub-schema just once, or
>     # include it first right here.

Thank you very much!!

Based on your inspiration, I think the ideal section structure for my
issue could be:

    = accelerator
    == KVM
    === PMU

Firstly, I should have a new accelerator.json () to include KVM stuff:

    ##
    # = Accelerator
    ##

    { 'include': 'kvm.json' }

Next, in kvm.json, I could organize stuffs like:

    ##
    # == KVM
    ##

    ##
    # === PMU stuff
    ##

    ... (the below are my current QPAI definitions.)

Is such a structure reasonable?

Thank you again for your guidance!

Regards,
Zhao



  reply	other threads:[~2025-04-01  7:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-22  9:05 [RFC v2 0/5] accel/kvm: Support KVM PMU filter Zhao Liu
2025-01-22  9:05 ` [RFC v2 1/5] qapi/qom: Introduce kvm-pmu-filter object Zhao Liu
2025-02-05 10:03   ` Markus Armbruster
2025-02-06 10:19     ` Zhao Liu
2025-02-06 10:27       ` Zhao Liu
2025-02-06 12:13       ` Markus Armbruster
2025-02-06 14:32         ` Zhao Liu
2025-02-07 13:02           ` Markus Armbruster
2025-04-01  7:47             ` Zhao Liu [this message]
2025-04-08  5:51               ` Markus Armbruster
2025-01-22  9:05 ` [RFC v2 2/5] i386/kvm: Support basic KVM PMU filter Zhao Liu
2025-01-22  9:05 ` [RFC v2 3/5] i386/kvm: Support event with select & umask format in " Zhao Liu
2025-02-05 10:07   ` Markus Armbruster
2025-02-06  9:54     ` Zhao Liu
2025-02-06  9:42       ` Daniel P. Berrangé
2025-02-06 10:23         ` Zhao Liu
2025-02-06 10:24         ` Markus Armbruster
2025-02-06 14:22           ` Zhao Liu
2025-02-06 14:54             ` Zhao Liu
2025-02-07 13:06               ` Markus Armbruster
2025-04-01  7:53                 ` Zhao Liu
2025-01-22  9:05 ` [RFC v2 4/5] i386/kvm: Support event with masked entry " Zhao Liu
2025-01-22  9:05 ` [RFC v2 5/5] i386/kvm: Support fixed counter " Zhao Liu
2025-01-24  8:00 ` [RFC v2 0/5] accel/kvm: Support " Lai, Yi
2025-03-18  7:35 ` Shaoqin Huang
2025-03-21  3:43   ` Zhao Liu
2025-03-31  6:32     ` Shaoqin Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z+uaGHiOkFJd6TAO@intel.com \
    --to=zhao1.liu@intel.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dapeng1.mi@intel.com \
    --cc=eauger@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=gshan@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sebott@redhat.com \
    --cc=shahuang@redhat.com \
    --cc=thuth@redhat.com \
    --cc=yi1.lai@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox