On 24/11/2023 8:41 am, Jan Beulich wrote: > ... to a struct field, which is then going to be accompanied by other > capability/control data presently living in individual variables. As > this structure isn't supposed to be altered post-boot, put it in > .data.ro_after_init right away. > > Suggested-by: Roger Pau Monné <[email protected]> > Signed-off-by: Jan Beulich <[email protected]>
For (usable) nested virt, we're going to need the VMX MSRs, in their architectural form, in struct cpu_policy. And just like CPUID features, I want it to end up with nice bitfields to use. Looking through the rest of this series, vmx_caps ends up almost in architectural form. Could I talk you into having a "struct vmx_msrs" (or similar - 'caps' doesn't feel quite right here) in the policy object, and also instantiating one instance of it for this purpose here? AFAICT, it would only be a minor deviation to the latter half of this series, but it would be an excellent start to fixing nested virt - and getting this data in the policy really is the first task in getting the ball rolling on nested virt. I don't mind about serialising/de-serialsing it - that still has a bit of userspace complexity to work out, and depends on some of the cleanup still needing a repost. If you don't want to take the added space in cpu_policy yet, how about having the declaration there and just forgo instantiating the subobject in the short term? ~Andrew
