From: Zhao Liu <zhao1.liu@intel.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Shaoqin Huang <shahuang@redhat.com>,
qemu-arm@nongnu.org, Eric Auger <eauger@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Huth <thuth@redhat.com>,
Laurent Vivier <lvivier@redhat.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org,
Zhao Liu <zhao1.liu@intel.com>,
Zhenyu Wang <zhenyu.z.wang@intel.com>,
Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [PATCH v9] arm/kvm: Enable support for KVM_ARM_VCPU_PMU_V3_FILTER
Date: Thu, 9 May 2024 17:48:19 +0800 [thread overview]
Message-ID: <Zjyb43JqMZA+bO4r@intel.com> (raw)
In-Reply-To: <Zh1j9b92UGPzr1-a@redhat.com>
Hi Daniel & Shaoqin,
Since x86 also needs to implement PMU filter feature, though it uses
the different KVM ioctl, we can still make the QEMU API as general as
possible.
To move forward with both ARM and x86, I'd like to discuss my API
thinking with you. ;-)
On Mon, Apr 15, 2024 at 06:29:25PM +0100, Daniel P. Berrangé wrote:
> Date: Mon, 15 Apr 2024 18:29:25 +0100
> From: "Daniel P. Berrangé" <berrange@redhat.com>
> Subject: Re: [PATCH v9] arm/kvm: Enable support for
> KVM_ARM_VCPU_PMU_V3_FILTER
>
> On Mon, Apr 08, 2024 at 10:49:40PM -0400, Shaoqin Huang wrote:
> > The KVM_ARM_VCPU_PMU_V3_FILTER provides the ability to let the VMM decide
> > which PMU events are provided to the guest. Add a new option
> > `kvm-pmu-filter` as -cpu sub-option to set the PMU Event Filtering.
> > Without the filter, all PMU events are exposed from host to guest by
> > default. The usage of the new sub-option can be found from the updated
> > document (docs/system/arm/cpu-features.rst).
> >
> > Here is an example which shows how to use the PMU Event Filtering, when
> > we launch a guest by use kvm, add such command line:
> >
> > # qemu-system-aarch64 \
> > -accel kvm \
> > -cpu host,kvm-pmu-filter="D:0x11-0x11"
>
> I'm still against implementing this one-off custom parsed syntax
> for kvm-pmu-filter values. Once this syntax exists, we're locked
> into back-compatibility for multiple releases, and it will make
> a conversion to QAPI/JSON harder.
Daniel, I understand you mean the new specific string format makes
external API support more complicated, right?
What about the following options:
1. Firstly, add a feature flag option in "-cpu" to enable kvm_filter
feature for CPU:
-cpu host,kvm-pmu-filter
2. Then use "-object kvm-pmu-event" to configure PMU event properties.
Since x86's PMU filter has very complex encoding rules, we need the
following three variants (one for general case, the other two are x86
specific):
- General format:
-object kvm-pmu-event,action=[allowed|denied],events=[event-list]
e.g, as Shaoqin's example,
-object kvm-pmu-event,action=allowed,events=0x11-0x11,0x23-0x23
-object kvm-pmu-event,action=denied,events=0x23-0x3a
- x86 raw_event encoding format (for single raw format event encoding):
-object kvm-pmu-event,action=[allowed|denied],mode=0,select="0x01",
umask="0x3c",fixed-bitmap="0xffffffff"
- x86 masked_event encoding format (for mutiple masked event encoding):
-object kvm-pmu-event,action=[allowed|denied],mode=masked,select="0x01",
mask="0x3c",match="0x11",exclude=true|false
The whole API architecture looks more complex, but has the advantage of
being as general as possible and avoiding the introduction of new string
format parsing.
What do you think? Because the most important thing about this feature
is the API design, welcome your comments!
Regards,
Zhao
next prev parent reply other threads:[~2024-05-09 9:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 2:49 [PATCH v9] arm/kvm: Enable support for KVM_ARM_VCPU_PMU_V3_FILTER Shaoqin Huang
2024-04-09 5:33 ` Thomas Huth
2024-04-09 7:47 ` Shaoqin Huang
2024-04-10 6:07 ` Thomas Huth
2024-04-16 15:17 ` Cornelia Huck
2024-04-15 17:29 ` Daniel P. Berrangé
2024-05-07 9:33 ` Shaoqin Huang
2024-05-09 9:48 ` Zhao Liu [this message]
2024-05-09 9:39 ` Daniel P. Berrangé
2024-05-13 6:52 ` Zhao Liu
2024-05-15 16:47 ` Daniel P. Berrangé
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=Zjyb43JqMZA+bO4r@intel.com \
--to=zhao1.liu@intel.com \
--cc=berrange@redhat.com \
--cc=dapeng1.mi@intel.com \
--cc=eauger@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shahuang@redhat.com \
--cc=thuth@redhat.com \
--cc=zhenyu.z.wang@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).