On Thu, 2023-02-16 at 13:31 +0800, Binbin Wu wrote: > On 2/14/2023 8:24 PM, Robert Hoo wrote: > > On Tue, 2023-02-14 at 17:00 +0800, Binbin Wu wrote: > > > According to the code of set_cr4_guest_host_mask, > > > vcpu->arch.cr4_guest_owned_bits is a subset of > > > KVM_POSSIBLE_CR4_GUEST_BITS, > > > and X86_CR4_LAM_SUP is not included in > > > KVM_POSSIBLE_CR4_GUEST_BITS. > > > No matter change CR4_RESERVED_BITS or not, X86_CR4_LAM_SUP will > > > always be set in CR4_GUEST_HOST_MASK. > > > > > > > > > > set_cr4_guest_host_mask(): > > vcpu->arch.cr4_guest_owned_bits = KVM_POSSIBLE_CR4_GUEST_BITS & > > ~vcpu->arch.cr4_guest_rsvd_bits; > > My point is when X86_CR4_LAM_SUP is not set in > KVM_POSSIBLE_CR4_GUEST_BITS, > CR4.LAM_SUP is definitely owned by host, regardless of the value of > cr4_guest_rsvd_bits. > Yes, you can disregard that reply. We were talking each's own points:) Neither is wrong. Chao talked to me afterwards, that your points are: we can say by default, without this patch, CR4.LAM_SUP were intercepted. so why redundantly name this patch "Intercept CR4.LAM_SUP". That's true, but intercepted as reserved bit. I'm revising the subject in v5. > > > > > kvm_vcpu_after_set_cpuid(): > > vcpu->arch.cr4_guest_rsvd_bits = > > __cr4_reserved_bits(guest_cpuid_has, vcpu); > >
