Clearing VM_EXIT_ACTIVATE_SECONDARY_CONTROLS may be problematic when new bits are added to secondary vmcs controls. Why not keep VM_EXIT_ACTIVATE_SECONDARY_CONTROLS always on if it is supported? or you see any perf impact?
I think it from the other way, why keeps hw loading it on every vmentry even if it's not used by a guest?
Oh, yeesh, this is clearing the activation control. Yeah, NAK to that, just leave it set. If it weren't for the fact that there is apparently a metrict ton of FRED state (I thought the whole point of FRED was to kill off legacy crap like CPL1 and CPL2 stacks?) _and_ that KVM needs to toggle MSR intercepts, I'd probably push back on toggling even the FRED controls.
To me, FRED is to _architecturally_ do the right thing for x86 event handling.
I don't think FRED's major purpose is to kill legacy craps, but longer term it paves the way for that.
Yeah, I would like to discuss whether to toggle FRED controls.
Different CPUs may implement it in different ways, which we can't assume.
Implement what in a different way? The VMCS fields and FRED are architectural. The internal layout of the VMCS is uarch specific, but the encodings and semantics absolutely cannot change without breaking software. And if Intel does something asinine like make a control active-low then we have far, far bigger problems.
I should have made it clear that I wasn't talking at the ISA level. And of course CPU uarch implementations should be transparent to software.
I mean a CPU uarch could choose to check the activation bit in the VM exit controls first and then decide whether to load the 2nd VM exit controls. While if resources allow, a CPU uarch could always load the 2nd VM exit controls.
BTW, I believe the active-low controls are really gone with new features. All new controls are all 0s by default.
Other features needing it should set it separately, say with a refcount.
Absolutely not. Unless Intel screwed up the implementation, the cost of leaving VM_EXIT_ACTIVATE_SECONDARY_CONTROLS set when it's supported shouldn't even be measurable.
I do hope so. However, I don't know whether this is guaranteed or not on all uarch implementations.
A decision to leave it set is good enough for now.
Thanks! Xin