On 09.01.2024 15:54, Andrew Cooper wrote: > On 09/01/2024 2:39 pm, Jan Beulich wrote: >> Even the inner struct plan falls apart pretty quickly (or grows what >> needs doing by too much for my taste, in the context right here): >> While for basic_msr this works, and it would apparently also work >> for vmfunc and tertiary exec control (the latter is itself only part >> of a yet to be reviewed / approved patch), it doesn't for all the >> others with split 0-setting and 1-setting halves. This is because >> what VMX code wants are the calculated values to put in the VMCS, >> whereas imo in the policy we'd want to store both halves (and what >> exactly wants to be in the host policy there isn't really clear to >> me). As a result I can't create a single uniform structure properly >> serving both purposes. Nor could I have VMX code use the host >> policy for most of its capability checks. >> >> Thought / ideas? > > If it's not actually trivial, then don't worry. > > The policy does need to hold the architectural representation. The > in-use settings need storing per-vCPU because they do (or need to me > made to) vary based on the configuration of the VM, and because they're > needed on every virtual vmentry when re-calculating VMCS02.
Would it help if I did a hybrid approach, i.e. move to raw/host policies only what can be easily moved, with the rest kept as is (perhaps with vmx_caps renamed to vmx_ctls then)? Jan
