> >> > > 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. > > Is it really too much to ask of the client to compute a raw value from > umask and select values? I understand you're wondering if we can omit the select+umask format... In principle, having either one should work correctly... The additional support for the umask+select format is more user-friendly and doesn't introduce much complexity in the code. My own observation is that Intel's doc rarely uses the raw format directly, whereas AMD uses the raw format relatively more often. Personally, when using the perf tool, I prefer the umask+select format. Even if only the raw format is supported, users still need to be aware of the umask+select format because there is the third format - "masked entry" (which tries to mask a group of events with same select, patch 4). So I would like to keep both raw and umask+select formats if possible. ... > >> > > +# > >> > > +# 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? > > Do users need to know how to compute the raw event value from @select > and @umask? Yes, because it's also a unified calculation. AMD and Intel have differences in bits for supported select field, but this calculation (which follows from the KVM code) makes both compatible. > If yes, is C code the best way? > > Here's another way: > > bits 0..7 : bits 0..7 of @select > bits 8..15: @umask > bits 24..27: bits 8..11 of @select > all other bits: zero > Thank you! This is what I want.
