On Thu, Dec 29, 2022, Robert Hoo wrote: > On Wed, 2022-12-28 at 11:37 +0800, Binbin Wu wrote: > > On 12/9/2022 12:45 PM, Robert Hoo wrote: > > > kvm_vcpu_arch::cr4_guest_owned_bits and > > > kvm_vcpu_arch::cr4_guest_rsvd_bits > > > looks confusing. Rename latter to cr4_host_rsvd_bits, because it in > > > fact decribes the effective host reserved cr4 bits from the vcpu's > > > perspective. > > > > IMO, the current name cr4_guest_rsvd_bits is OK becuase it shows that these > > bits are reserved bits from the pointview of guest. > > Actually, it's cr4_guest_owned_bits that from the perspective of guest. No, cr4_guest_owned_bits is KVM's view of things. It tracks which bits have effectively been passed through to the guest and so need to be read out of the VMCS after running the vCPU. > cr4_guest_owned_bits and cr4_guest_rsvd_bits together looks quite > confusing. I disagree, KVM (and the SDM and the APM) uses "reserved" or "rsvd" all over the place to indicate reserved bits/values/fields. > > > * cr4_reserved_bits --> cr4_kvm_reserved_bits, which describes Hard no. They aren't just KVM reserved, many of those bits are reserved by hardware, which is 100% dependent on the host. > > > CR4_HOST_RESERVED_BITS + !kvm_cap_has() = kvm level cr4 reserved > > > bits. > > > > > > * __cr4_reserved_bits() --> __cr4_calc_reserved_bits(), which to > > > calc > > > effective cr4 reserved bits for kvm or vm level, by corresponding > > > x_cpu_has() input. > > > > > > Thus, by these renames, the hierarchical relations of those reserved CR4 > > > bits is more clear. Sorry, but I don't like any of the changes in this patch. At best, some of the changes are a wash (neither better nor worse), and in that case the churn, however minor isn't worth it.
