On Thu, Apr 25, 2024, Wei W Wang wrote: > On Wednesday, April 24, 2024 6:15 AM, Sean Christopherson wrote: > > @@ -403,7 +403,7 @@ static void vmx_update_fb_clear_dis(struct kvm_vcpu > > *vcpu, struct vcpu_vmx *vmx) > > * and VM-Exit. > > */ > > vmx->disable_fb_clear > > = !cpu_feature_enabled(X86_FEATURE_CLEAR_CPU_BUF) && > > - (host_arch_capabilities & > > ARCH_CAP_FB_CLEAR_CTRL) && > > + (kvm_host.arch_capabilities & > > ARCH_CAP_FB_CLEAR_CTRL) && > > The line of code appears to be lengthy. It would be preferable to limit it to under > 80 columns per line. I agree that staying under 80 is generally preferred, but I find this vmx->disable_fb_clear = (kvm_host.arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) && !boot_cpu_has_bug(X86_BUG_MDS) && !boot_cpu_has_bug(X86_BUG_TAA); much more readable than this vmx->disable_fb_clear = (kvm_host.arch_capabilities & ARCH_CAP_FB_CLEAR_CTRL) && !boot_cpu_has_bug(X86_BUG_MDS) && !boot_cpu_has_bug(X86_BUG_TAA); We should shorten the name to arch_caps, but I don't think that's a net positive, e.g. unless we do a bulk rename, it'd diverge from several other functions/variables, and IMO it would be less obvious that the field holds MSR_IA32_ARCH_CAPABILITIES. > > !boot_cpu_has_bug(X86_BUG_MDS) && > > !boot_cpu_has_bug(X86_BUG_TAA); > > > > @@ -325,11 +332,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, > > gpa_t cr2_or_gpa, > > int emulation_type, void *insn, int insn_len); > > fastpath_t handle_fastpath_set_msr_irqoff(struct kvm_vcpu *vcpu); > > > > -extern u64 host_xcr0; > > -extern u64 host_xss; > > -extern u64 host_arch_capabilities; > > - > > extern struct kvm_caps kvm_caps; > > +extern struct kvm_host_values kvm_host; > > Have you considered merging the kvm_host_values and kvm_caps into one unified > structure? No really. I don't see any benefit, only the downside of having to come up with a name that is intuitive when reading code related to both. > (If the concern is about naming, we could brainstorm a more encompassing term > for them)
