From: Shaoqin Huang <shahuang@redhat.com>
To: "Zhao Liu" <zhao1.liu@intel.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Michael Roth" <michael.roth@amd.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcelo Tosatti" <mtosatti@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>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, qemu-arm@nongnu.org,
Dapeng Mi <dapeng1.mi@intel.com>, Yi Lai <yi1.lai@intel.com>
Subject: Re: [RFC v2 0/5] accel/kvm: Support KVM PMU filter
Date: Tue, 18 Mar 2025 15:35:24 +0800 [thread overview]
Message-ID: <2fe2a98d-f70f-4996-b04e-d81f66d5863f@redhat.com> (raw)
In-Reply-To: <20250122090517.294083-1-zhao1.liu@intel.com>
Hi Zhao,
Thanks for your effort to respin the PMU Filter series.
I tried your series on ARM64, but it reports error at compile time, here
is the error output:
qapi/kvm.json:59:Unexpected indentation.
While I compiled it on x86, everything is ok. Could you please check why
it failed on ARM64?
By the mean time, I will review and test this series.
Thanks,
Shaoqin
On 1/22/25 5:05 PM, Zhao Liu wrote:
> Hi folks,
>
> Sorry for the long wait, but RFC v2 is here at last.
>
> Compared with v1 [1], v2 mianly makes `action` as a global parameter,
> and all events (and fixed counters) are based on a unified action.
>
> Learned from the discussion with Shaoqin in v1, current pmu-filter QOM
> design could meet the requirements from the ARM KVM side.
>
>
> Background
> ==========
>
> I picked up Shaoqing's previous work [2] on the KVM PMU filter for arm,
> and now is trying to support this feature for x86 with a JSON-compatible
> API.
>
> While arm and x86 use different KVM ioctls to configure the PMU filter,
> considering they all have similar inputs (PMU event + action), it is
> still possible to abstract a generic, cross-architecture kvm-pmu-filter
> object and provide users with a sufficiently generic or near-consistent
> QAPI interface.
>
> That's what I did in this series, a new kvm-pmu-filter object, with the
> API like:
>
> -object '{"qom-type":"kvm-pmu-filter","id":"f0","action":"allow","events":[{"format":"raw","code":"0xc4"}]}'
>
> For i386, this object is inserted into kvm accelerator and is extended
> to support fixed-counter and more formats ("x86-default" and
> "x86-masked-entry"):
>
> -accel kvm,pmu-filter=f0 \
> -object pmu='{"qom-type":"kvm-pmu-filter","id":"f0","action":"allow","x86-fixed-counter":{"bitmap":"0x0"},"events":[{"format":"x86-masked-entry","select":"0xc4","mask":"0xff","match":"0","exclude":true},{"format":"x86-masked-entry","select":"0xc5","mask":"0xff","match":"0","exclude":true}]}'
>
> This object can still be added as the property to the arch CPU if it is
> desired as a per CPU feature (as Shaoqin did for arm before).
>
>
> Introduction
> ============
>
>
> Formats supported in kvm-pmu-filter
> -----------------------------------
>
> This series supports 3 formats:
>
> * raw format (general format).
>
> This format indicates the code that has been encoded to be able to
> index the PMU events, and which can be delivered directly to the KVM
> ioctl. For arm, this means the event code, and for i386, this means
> the raw event with the layout like:
>
> select high bit | umask | select low bits
>
> * x86-default format (i386 specific)
>
> x86 commonly uses select&umask to identify PMU events, and this format
> is used to support the select&umask. Then QEMU will encode select and
> umask into a raw format code.
>
> * x86-masked-entry (i386 specific)
>
> This is a special format that x86's KVM_SET_PMU_EVENT_FILTER supports.
>
>
> Hexadecimal value string
> ------------------------
>
> In practice, the values associated with PMU events (code for arm, select&
> umask for x86) are often expressed in hexadecimal. Further, from linux
> perf related information (tools/perf/pmu-events/arch/*/*/*.json), x86/
> arm64/riscv/nds32/powerpc all prefer the hexadecimal numbers and only
> s390 uses decimal value.
>
> Therefore, it is necessary to support hexadecimal in order to honor PMU
> conventions.
>
> However, unfortunately, standard JSON (RFC 8259) does not support
> hexadecimal numbers. So I can only consider using the numeric string in
> the QAPI and then parsing it to a number.
>
> To achieve this, I defined two versions of PMU-related structures in
> kvm.json:
> * a native version that accepts numeric values, which is used for
> QEMU's internal code processing,
>
> * and a variant version that accepts numeric string, which is used to
> receive user input.
>
> kvm-pmu-filter object will take care of converting the string version
> of the event/counter information into the numeric version.
>
> The related implementation can be found in patch 1.
>
>
> CPU property v.s. KVM property
> ------------------------------
>
> In Shaoqin's previous implementation [2], KVM PMU filter is made as a
> arm CPU property. This is because arm uses a per CPU ioctl
> (KVM_SET_DEVICE_ATTR) to configure KVM PMU filter.
>
> However, for x86, the dependent ioctl (KVM_SET_PMU_EVENT_FILTER) is per
> VM. In the meantime, considering that for hybrid architecture, maybe in
> the future there will be a new per vCPU ioctl, or there will be
> practices to support filter fixed counter by configuring CPUIDs.
>
> Based on the above thoughts, for x86, it is not appropriate to make the
> current per-VM ioctl-based PMU filter a CPU property. Instead, I make it
> a kvm property and configure it via "-accel kvm,pmu-filter=obj_id".
>
> So in summary, it is feasible to use the KVM PMU filter as either a CPU
> or a KVM property, depending on whether it is used as a CPU feature or a
> VM feature.
>
> The kvm-pmu-filter object, as an abstraction, is general enough to
> support filter configurations for different scopes (per-CPU or per-VM).
>
> [1]: https://lore.kernel.org/qemu-devel/20240710045117.3164577-1-zhao1.liu@intel.com/
> [2]: https://lore.kernel.org/qemu-devel/20240409024940.180107-1-shahuang@redhat.com/
>
> Thanks and Best Regards,
> Zhao
> ---
> Zhao Liu (5):
> qapi/qom: Introduce kvm-pmu-filter object
> i386/kvm: Support basic KVM PMU filter
> i386/kvm: Support event with select & umask format in KVM PMU filter
> i386/kvm: Support event with masked entry format in KVM PMU filter
> i386/kvm: Support fixed counter in KVM PMU filter
>
> MAINTAINERS | 1 +
> accel/kvm/kvm-pmu.c | 386 +++++++++++++++++++++++++++++++++++++++
> accel/kvm/meson.build | 1 +
> include/system/kvm-pmu.h | 44 +++++
> include/system/kvm_int.h | 2 +
> qapi/kvm.json | 246 +++++++++++++++++++++++++
> qapi/meson.build | 1 +
> qapi/qapi-schema.json | 1 +
> qapi/qom.json | 3 +
> target/i386/kvm/kvm.c | 176 ++++++++++++++++++
> 10 files changed, 861 insertions(+)
> create mode 100644 accel/kvm/kvm-pmu.c
> create mode 100644 include/system/kvm-pmu.h
> create mode 100644 qapi/kvm.json
>
--
Shaoqin
next prev parent reply other threads:[~2025-03-18 7:38 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
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 [this message]
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=2fe2a98d-f70f-4996-b04e-d81f66d5863f@redhat.com \
--to=shahuang@redhat.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=thuth@redhat.com \
--cc=yi1.lai@intel.com \
--cc=zhao1.liu@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 NNTP newsgroup(s).