On 5/1/24 11:45, Sean Christopherson wrote: > On Sun, Feb 18, 2024, Yang Weijiang wrote: >> Define a new XFEATURE_MASK_KERNEL_DYNAMIC mask to specify the features > I still don't understand why this is being called DYNAMIC. CET_SS isn't dynamic, > as KVM is _always_ allowed to save/restore CET_SS, i.e. whether or not KVM can > expose CET_SS to a guest is a static, boot-time decision. Whether or not a guest > XSS actually enables CET_SS is "dynamic", but that's true of literally every > xfeature in XCR0 and XSS. > > XFEATURE_MASK_XTILE_DATA is labeled as dynamic because userspace has to explicitly > request that XTILE_DATA be enabled, and thus whether or not KVM is allowed to > expose XTILE_DATA to the guest is a dynamic, runtime decision. > > So IMO, the umbrella macro should be XFEATURE_MASK_KERNEL_GUEST_ONLY. Here's how I got that naming. First, "static" features are always there. "Dynamic" features might or might not be there. I was also much more focused on what's in the XSAVE buffer than on the enabling itself, which are _slightly_ different. Then, it's a matter of whether the feature is user or supervisor. The kernel might need new state for multiple reasons. Think of LBR state as an example. The kernel might want LBR state around for perf _or_ so it can be exposed to a guest. I just didn't want to tie it to "GUEST" too much in case we have more of these things come along that get used for things unrelated to KVM. Obviously, at this point, we've only got one and KVM is the only user so the delta that I was worried about doesn't actually exist. So I still prefer calling it "KERNEL" over "GUEST". But I also don't feel strongly about it and I've said my peace. I won't NAK it one way or the other.
