On 11.11.2025 21:10, Grygorii Strashko wrote: > From: Grygorii Strashko <[email protected]> > > The Cache Disable mode data is used only by VMX code, so move it from > common HVM structures into VMX specific structures: > - move "uc_lock", "is_in_uc_mode" fields from struct hvm_domain to struct > vmx_domain; > - move "cache_mode" field from struct hvm_vcpu to struct vmx_vcpu. > > Hence, the "in_uc_mode" field is used directly in mm/shadow/multi.c > _sh_propagate(), introduce the hvm_is_in_uc_mode() macro to avoid direct > access to this field and account for INTEL_VMX configuration. > > While here: > - rename "is_in_uc_mode" to "in_uc_mode" > - s/NORMAL_CACHE_MODE/CACHE_MODE_NORMAL > - s/NO_FILL_CACHE_MODE/CACHE_MODE_NO_FILL > > Suggested-by: Andrew Cooper <[email protected]> > Signed-off-by: Grygorii Strashko <[email protected]>
Reviewed-by: Jan Beulich <[email protected]> > @@ -158,6 +166,11 @@ struct vmx_vcpu { > > uint8_t lbr_flags; > > + /* Which cache mode is this VCPU in (CR0:CD/NW)? */ > + uint8_t cache_mode; > +#define CACHE_MODE_NORMAL 0 > +#define CACHE_MODE_NO_FILL 2 I wonder though whether the odd use of 0 and 2 (rather than 0 and 1) needs retaining ... > --- a/xen/arch/x86/include/asm/mtrr.h > +++ b/xen/arch/x86/include/asm/mtrr.h > @@ -7,9 +7,6 @@ > #define MEMORY_NUM_TYPES MTRR_NUM_TYPES > #define NO_HARDCODE_MEM_TYPE MTRR_NUM_TYPES > > -#define NORMAL_CACHE_MODE 0 > -#define NO_FILL_CACHE_MODE 2 ... from how it was. Jan
