On Fri, Dec 12, 2025 at 08:51:34PM +0000, Colton Lewis wrote:
The other reason for doing this is kvm_pmu_fgt_bits() assumes a 'positive' trap polarity, even though there are several cases where FGTs have a 'negative' priority (i.e. 0 => trap).
For the bits I was concerned with they all had positive polarity, except for the dedicated instruction counter. (Side note: Why would ARM do this?)
Old software on new hardware, you don't want the guest to magically get access to things it shouldn't.
IIRC the FGT setup I plugged into in previous versions of the patch had some icky macros that accounted for polarity. They were confusing and I didn't like the effort to understand them.
I'm guessing you're referring to the undef infrastructure (FGUs), which is a meaningfully load-bearing part of KVM.
Is there a good reason not to adopt a convetion that 1 => trap for kernel code? Reversing the negative polarities immediately before write could be easy: Have a bitmap of the negative polarity bits to xor with the traps we actually want.
This *significantly* muddies the water around FGTs. I quite like that the current representation matches the architecture. NV forces KVM to deal with the native representations anyway.
Thanks, Oliver