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>
Subject: Re: [PATCH 3/5] i386/kvm: Support event with select & umask format in KVM PMU filter
Date: Sun, 27 Apr 2025 14:49:29 +0800 [thread overview]
Message-ID: <aA3TeaYG9mNMdEiW@intel.com> (raw)
In-Reply-To: <87frhwfuv1.fsf@pond.sub.org>
Hi Markus,
> > + case KVM_PMU_EVENT_FORMAT_X86_SELECT_UMASK: {
> > + if (event->u.x86_select_umask.select > UINT12_MAX) {
> > + error_setg(errp,
> > + "Parameter 'select' out of range (%d).",
> > + UINT12_MAX);
> > + goto fail;
> > + }
> > +
> > + /* No need to check the range of umask since it's uint8_t. */
> > + break;
> > + }
>
> As we'll see below, the new x86-specific format is defined in the QAPI
> schema regardless of target.
>
> It is accepted here also regardless of target. Doesn't matter much
> right now, as the object is effectively useless for targets other than
> x86, but I understand that will change.
>
> Should we reject it unless the target is x86?
I previously supposed that different architectures should implement
their own kvm_arch_check_pmu_filter(), which is the `check` hook of
object_class_property_add_link():
object_class_property_add_link(oc, "pmu-filter",
TYPE_KVM_PMU_FILTER,
offsetof(KVMState, pmu_filter),
kvm_arch_check_pmu_filter,
OBJ_PROP_LINK_STRONG);
For x86, I implemented kvm_arch_check_pmu_filter() in target/i386/kvm/
kvm.c and checked the supported formats (I also supposed arch-specific
PMU filter could reject the unsupported format in
kvm_arch_check_pmu_filter().)
But I think your idea is better, i.e., rejecting unsupported format
early in pmu-filter parsing.
Well, IIUC, there is no way to specify in QAPI that certain enumerations
are generic and certain enumerations are arch-specific, so rejecting
unsupported format can only happen in parsing code. For example, wrap
the above code in "#if defined(TARGET_I386)":
for (node = head; node; node = node->next) {
KvmPmuFilterEvent *event = node->value;
switch (event->format) {
case KVM_PMU_EVENT_FORMAT_RAW:
break;
#if defined(TARGET_I386)
case KVM_PMU_EVENT_FORMAT_X86_SELECT_UMASK: {
...
break;
}
case KVM_PMU_EVENT_FORMAT_X86_MASKED_ENTRY: {
...
break;
}
#endif
default:
error_setg(errp,
"Unsupported format.");
goto fail;
}
...
}
EMM, do you like this idea?
> If not, I feel the behavior should be noted in the commit message.
With the above change, I think it's possible to reject x86-specific
format on non-x86 arch. And I can also note this behavior in commit
message.
> > default:
> > g_assert_not_reached();
> > }
> > @@ -67,6 +82,9 @@ static void kvm_pmu_filter_set_event(Object *obj, Visitor *v, const char *name,
> > filter->events = head;
> > qapi_free_KvmPmuFilterEventList(old_head);
> > return;
> > +
> > +fail:
> > + qapi_free_KvmPmuFilterEventList(head);
> > }
> >
> > static void kvm_pmu_filter_class_init(ObjectClass *oc, void *data)
...
> > ##
> > # @KvmPmuFilterEvent:
> > #
> > @@ -66,7 +82,8 @@
> > { 'union': 'KvmPmuFilterEvent',
> > 'base': { 'format': 'KvmPmuEventFormat' },
> > 'discriminator': 'format',
> > - 'data': { 'raw': 'KvmPmuRawEvent' } }
> > + 'data': { 'raw': 'KvmPmuRawEvent',
> > + 'x86-select-umask': 'KvmPmuX86SelectUmaskEvent' } }
> >
> > ##
> > # @KvmPmuFilterProperties:
>
> Documentation could perhaps be more explicit about this making sense
> only for x86.
What about the following doc?
##
# @KvmPmuFilterProperties:
#
# Properties of KVM PMU Filter (only for x86).
> > diff --git a/qemu-options.hx b/qemu-options.hx
> > index 51a7c61ce0b0..5dcce067d8dd 100644
> > --- a/qemu-options.hx
> > +++ b/qemu-options.hx
> > @@ -6180,6 +6180,9 @@ SRST
> > ((select) & 0xff) | \
> > ((umask) & 0xff) << 8)
> >
> > + ``{"format":"x86-select-umask","select":event_select,"umask":event_umask}``
> > + Specify the single x86 PMU event with select and umask fields.
> > +
> > An example KVM PMU filter object would look like:
> >
> > .. parsed-literal::
> > diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> > index fa3a696654cb..0d36ccf250ed 100644
> > --- a/target/i386/kvm/kvm.c
> > +++ b/target/i386/kvm/kvm.c
> > @@ -5974,6 +5974,10 @@ static bool kvm_config_pmu_event(KVMPMUFilter *filter,
> > case KVM_PMU_EVENT_FORMAT_RAW:
> > code = event->u.raw.code;
> > break;
> > + case KVM_PMU_EVENT_FORMAT_X86_SELECT_UMASK:
> > + code = X86_PMU_RAW_EVENT(event->u.x86_select_umask.select,
> > + event->u.x86_select_umask.umask);
> > + break;
> > default:
> > g_assert_not_reached();
> > }
> > @@ -6644,6 +6648,7 @@ static void kvm_arch_check_pmu_filter(const Object *obj, const char *name,
> >
> > switch (event->format) {
> > case KVM_PMU_EVENT_FORMAT_RAW:
> > + case KVM_PMU_EVENT_FORMAT_X86_SELECT_UMASK:
Here's the current format check I mentioned above. But I agree your idea
and will check in the parsing of pmu-filter object.
> > break;
> > default:
> > error_setg(errp,
>
next prev parent reply other threads:[~2025-04-27 6:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 8:26 [PATCH 0/5] accel/kvm: Support KVM PMU filter Zhao Liu
2025-04-09 8:26 ` [PATCH 1/5] qapi/qom: Introduce kvm-pmu-filter object Zhao Liu
2025-04-10 14:21 ` Markus Armbruster
2025-04-11 4:03 ` Zhao Liu
2025-04-11 4:38 ` Markus Armbruster
2025-04-11 6:34 ` Zhao Liu
2025-04-16 8:17 ` Markus Armbruster
2025-04-24 6:33 ` Zhao Liu
2025-04-25 10:35 ` Philippe Mathieu-Daudé
2025-04-27 7:26 ` Zhao Liu
2025-04-24 12:18 ` Markus Armbruster
2025-04-24 15:34 ` Zhao Liu
2025-04-25 9:19 ` Markus Armbruster
2025-04-09 8:26 ` [PATCH 2/5] i386/kvm: Support basic KVM PMU filter Zhao Liu
2025-04-25 9:19 ` Markus Armbruster
2025-04-27 8:34 ` Zhao Liu
2025-04-28 6:12 ` Markus Armbruster
2025-04-28 14:12 ` Zhao Liu
2025-04-09 8:26 ` [PATCH 3/5] i386/kvm: Support event with select & umask format in " Zhao Liu
2025-04-25 9:33 ` Markus Armbruster
2025-04-27 6:49 ` Zhao Liu [this message]
2025-04-28 7:19 ` Markus Armbruster
2025-04-28 14:42 ` Zhao Liu
2025-04-28 16:24 ` Markus Armbruster
2025-04-29 6:24 ` Zhao Liu
2025-04-09 8:26 ` [PATCH 4/5] i386/kvm: Support event with masked entry " Zhao Liu
2025-04-25 9:37 ` Markus Armbruster
2025-04-09 8:26 ` [PATCH 5/5] i386/kvm: Support fixed counter " Zhao Liu
2025-04-24 8:17 ` Mi, Dapeng
2025-04-24 15:35 ` Zhao Liu
2025-04-25 10:32 ` Philippe Mathieu-Daudé
2025-04-27 7:35 ` Zhao Liu
2025-04-15 7:49 ` [PATCH 0/5] accel/kvm: Support " Shaoqin Huang
2025-04-15 9:59 ` Zhao Liu
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=aA3TeaYG9mNMdEiW@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.