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
