Re: [RFC v2 3/5] i386/kvm: Support event with select & umask format in KVM PMU filter

[Zhao Liu <zhao1.liu@intel.com>]

On Wed, Feb 05, 2025 at 11:07:10AM +0100, Markus Armbruster wrote:
> Date: Wed, 05 Feb 2025 11:07:10 +0100
> From: Markus Armbruster <armbru@redhat.com>
> Subject: Re: [RFC v2 3/5] i386/kvm: Support event with select & umask
>  format in KVM PMU filter
> 
> Zhao Liu <zhao1.liu@intel.com> writes:
> 
> > The select&umask is the common way for x86 to identify the PMU event,
> > so support this way as the "x86-default" format in kvm-pmu-filter
> > object.
> 
> So, format 'raw' lets you specify the PMU event code as a number, wheras
> 'x86-default' lets you specify it as select and umask, correct?

Yes!

> Why do we want both?

This 2 formats are both wildly used in x86(for example, in perf tool).

x86 documents usually specify the umask and select fields.

But raw format could also be applied for ARM since ARM just uses a number
to encode event.

> > Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> 
> [...]
> 
> > diff --git a/qapi/kvm.json b/qapi/kvm.json
> > index d51aeeba7cd8..93b869e3f90c 100644
> > --- a/qapi/kvm.json
> > +++ b/qapi/kvm.json
> > @@ -27,11 +27,13 @@
> >  #
> >  # @raw: the encoded event code that KVM can directly consume.
> >  #
> > +# @x86-default: standard x86 encoding format with select and umask.
> 
> Why is this named -default?

Intel and AMD both use umask+select to encode events, but this format
doesn't have a name... so I call it `default`, or what about
"x86-umask-select"?

> > +#
> >  # Since 10.0
> >  ##
> >  { 'enum': 'KVMPMUEventEncodeFmt',
> >    'prefix': 'KVM_PMU_EVENT_FMT',
> > -  'data': ['raw'] }
> > +  'data': ['raw', 'x86-default'] }
> >  
> >  ##
> >  # @KVMPMURawEvent:
> > @@ -46,6 +48,25 @@
> >  { 'struct': 'KVMPMURawEvent',
> >    'data': { 'code': 'uint64' } }
> >  
> > +##
> > +# @KVMPMUX86DefalutEvent:
> 
> Default, I suppose.

Thanks!

> > +#
> > +# x86 PMU event encoding with select and umask.
> > +# raw_event = ((select & 0xf00UL) << 24) | \
> > +#              (select) & 0xff) | \
> > +#              ((umask) & 0xff) << 8)
> 
> Sphinx rejects this with "Unexpected indentation."
> 
> Is the formula needed here?

I tried to explain the relationship between raw format and umask+select.

Emm, where do you think is the right place to put the document like
this?

...

> > +##
> > +# @KVMPMUX86DefalutEventVariant:
> > +#
> > +# The variant of KVMPMUX86DefalutEvent with the string, rather than
> > +# the numeric value.
> > +#
> > +# @select: x86 PMU event select field.  This field is a 12-bit
> > +#     unsigned number string.
> > +#
> > +# @umask: x86 PMU event umask field. This field is a uint8 string.
> 
> Why are these strings?  How are they parsed into numbers?

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.

I parse this string into number by qemu_strtou64().