| Message ID | 20241101183555.1794700-10-seanjc@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | KVM: x86: Clean up MSR_IA32_APICBASE_BASE code | expand |
On Fri, 2024-11-01 at 11:35 -0700, Sean Christopherson wrote: > Do nothing in from kvm_apic_set_base() if the incoming MSR value is the > same as the current value, as validating the mode transitions is obviously > unnecessary, and rejecting the write is pointless if the vCPU already has > an invalid value, e.g. if userspace is doing weird things and modified > guest CPUID after setting MSR_IA32_APICBASE. > > Bailing early avoids kvm_recalculate_apic_map()'s slow path in the rare > scenario where the map is DIRTY due to some other vCPU dirtying the map, > in which case it's the other vCPU/task's responsibility to recalculate the > map. > > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/lapic.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > index 7b2342e40e4e..59a64b703aad 100644 > --- a/arch/x86/kvm/lapic.c > +++ b/arch/x86/kvm/lapic.c > @@ -2582,9 +2582,6 @@ static void __kvm_apic_set_base(struct kvm_vcpu *vcpu, u64 value) > u64 old_value = vcpu->arch.apic_base; > struct kvm_lapic *apic = vcpu->arch.apic; > > - if (old_value == value) > - return; > - Could you clarify why this is removed? AFAICT kvm_lapic_reset() still calls directly. > vcpu->arch.apic_base = value; > > if ((old_value ^ value) & MSR_IA32_APICBASE_ENABLE) > @@ -2632,6 +2629,10 @@ int kvm_apic_set_base(struct kvm_vcpu *vcpu, u64 value, bool host_initiated) > { > enum lapic_mode old_mode = kvm_get_apic_mode(vcpu); > enum lapic_mode new_mode = kvm_apic_mode(value); > + > + if (vcpu->arch.apic_base == value) > + return 0; > + > u64 reserved_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu) | 0x2ff | > (guest_cpuid_has(vcpu, X86_FEATURE_X2APIC) ? 0 : X2APIC_ENABLE); > > -- > 2.47.0.163.g1226f6d8fa-goog >
On Mon, Nov 04, 2024, Kai Huang wrote: > On Fri, 2024-11-01 at 11:35 -0700, Sean Christopherson wrote: > > Do nothing in from kvm_apic_set_base() if the incoming MSR value is the > > same as the current value, as validating the mode transitions is obviously > > unnecessary, and rejecting the write is pointless if the vCPU already has > > an invalid value, e.g. if userspace is doing weird things and modified > > guest CPUID after setting MSR_IA32_APICBASE. > > > > Bailing early avoids kvm_recalculate_apic_map()'s slow path in the rare > > scenario where the map is DIRTY due to some other vCPU dirtying the map, > > in which case it's the other vCPU/task's responsibility to recalculate the > > map. > > > > Signed-off-by: Sean Christopherson <seanjc@google.com> > > --- > > arch/x86/kvm/lapic.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > index 7b2342e40e4e..59a64b703aad 100644 > > --- a/arch/x86/kvm/lapic.c > > +++ b/arch/x86/kvm/lapic.c > > @@ -2582,9 +2582,6 @@ static void __kvm_apic_set_base(struct kvm_vcpu *vcpu, u64 value) > > u64 old_value = vcpu->arch.apic_base; > > struct kvm_lapic *apic = vcpu->arch.apic; > > > > - if (old_value == value) > > - return; > > - > > Could you clarify why this is removed? AFAICT kvm_lapic_reset() still calls > directly. It does, but in that case, @old_value is guaranteed to be zero, and @value is guaranteed to be non-zero, i.e. the check is unnecesary. At that point, the check in __kvm_apic_set_base() is 100% dead code, and I think it would do more harm than good, e.g. might confuse readers. I thought about adding a WARN, but that seems excessive. That said, the changelog definitely needs to explain why the check is moved from __kvm_apic_set_base(), as opposed to another check being added. How about this? -- Do nothing in all of kvm_apic_set_base(), not just __kvm_apic_set_base(), if the incoming MSR value is the same as the current value. Validating the mode transitions is obviously unnecessary, and rejecting the write is pointless if the vCPU already has an invalid value, e.g. if userspace is doing weird things and modified guest CPUID after setting MSR_IA32_APICBASE. Bailing early avoids kvm_recalculate_apic_map()'s slow path in the rare scenario where the map is DIRTY due to some other vCPU dirtying the map, in which case it's the other vCPU/task's responsibility to recalculate the map. Note, kvm_lapic_reset() calls __kvm_apic_set_base() only when emulating RESET, in which case the old value is guaranteed to be zero, and the new value is guaranteed to be non-zero. I.e. all callers of __kvm_apic_set_base() effectively pre-check for the MSR value actually changing. Don't bother keeping the check in __kvm_apic_set_base(), as no additional callers are expected, and implying that the MSR might already be non-zero at the time of kvm_lapic_reset() could confuse readers. --
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 7b2342e40e4e..59a64b703aad 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -2582,9 +2582,6 @@ static void __kvm_apic_set_base(struct kvm_vcpu *vcpu, u64 value) u64 old_value = vcpu->arch.apic_base; struct kvm_lapic *apic = vcpu->arch.apic; - if (old_value == value) - return; - vcpu->arch.apic_base = value; if ((old_value ^ value) & MSR_IA32_APICBASE_ENABLE) @@ -2632,6 +2629,10 @@ int kvm_apic_set_base(struct kvm_vcpu *vcpu, u64 value, bool host_initiated) { enum lapic_mode old_mode = kvm_get_apic_mode(vcpu); enum lapic_mode new_mode = kvm_apic_mode(value); + + if (vcpu->arch.apic_base == value) + return 0; + u64 reserved_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu) | 0x2ff | (guest_cpuid_has(vcpu, X86_FEATURE_X2APIC) ? 0 : X2APIC_ENABLE);
Do nothing in from kvm_apic_set_base() if the incoming MSR value is the same as the current value, as validating the mode transitions is obviously unnecessary, and rejecting the write is pointless if the vCPU already has an invalid value, e.g. if userspace is doing weird things and modified guest CPUID after setting MSR_IA32_APICBASE. Bailing early avoids kvm_recalculate_apic_map()'s slow path in the rare scenario where the map is DIRTY due to some other vCPU dirtying the map, in which case it's the other vCPU/task's responsibility to recalculate the map. Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/x86/kvm/lapic.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)