Re: [PATCH 5/7] KVM: x86: Move kvm_set_apic_base() implementation to lapic.c (from x86.c)

From: Sean Christopherson
Date: Mon Oct 14 2024 - 15:06:14 EST


On Mon, Oct 14, 2024, Kai Huang wrote:
> On Wed, 2024-10-09 at 11:17 -0700, Sean Christopherson wrote:
> > Move kvm_set_apic_base() to lapic.c so that the bulk of KVM's local APIC
> > code resides in lapic.c, regardless of whether or not KVM is emulating the
> > local APIC in-kernel. This will also allow making various helpers visible
> > only to lapic.c.
> >
> > No functional change intended.
> >
> > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> > ---
> > arch/x86/kvm/lapic.c | 21 +++++++++++++++++++++
> > arch/x86/kvm/x86.c | 21 ---------------------
> > 2 files changed, 21 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index fe30f465611f..6239cfd89aad 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -2628,6 +2628,27 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64 value)
> > }
> > }
> >
> > +int kvm_set_apic_base(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
> > +{
> > + enum lapic_mode old_mode = kvm_get_apic_mode(vcpu);
> > + enum lapic_mode new_mode = kvm_apic_mode(msr_info->data);
> > + u64 reserved_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu) | 0x2ff |
> > + (guest_cpuid_has(vcpu, X86_FEATURE_X2APIC) ? 0 : X2APIC_ENABLE);
> > +
> > + if ((msr_info->data & reserved_bits) != 0 || new_mode == LAPIC_MODE_INVALID)
> > + return 1;
> > + if (!msr_info->host_initiated) {
> > + if (old_mode == LAPIC_MODE_X2APIC && new_mode == LAPIC_MODE_XAPIC)
> > + return 1;
> > + if (old_mode == LAPIC_MODE_DISABLED && new_mode == LAPIC_MODE_X2APIC)
> > + return 1;
> > + }
> > +
> > + kvm_lapic_set_base(vcpu, msr_info->data);
> > + kvm_recalculate_apic_map(vcpu->kvm);
> > + return 0;
> > +}
>
> Nit:
>
> It is a little bit weird to use 'struct msr_data *msr_info' as function
> parameter if kvm_set_apic_base() is in lapic.c. Maybe we can change to take
> apic_base and host_initialized directly.
>
> A side gain is we can get rid of using the 'struct msr_data apic_base_msr' local
> variable in __set_sregs_common() when calling kvm_apic_set_base():

Ooh, nice. I agree, it'd be better to pass in separate parameters.

Gah, and looking at this with fresh eyes reminded me why I even started poking at
this code in the first place. Patch 1's changelog does a poor job of calling it
out, but the main impetus for this series was to avoid kvm_recalculate_apic_map()
when doing KVM_SET_SREGS without modifying APIC_BASE. That's _mostly_ handled by
patch 1, but it doesn't completely fix things because if the map is already DIRTY,
then KVM will unnecessarily fall into kvm_recalculate_apic_map()'s slow path, even
though some other vCPU/task is responsible for refreshing the calculation.

I'll send a v2 with your suggested change, a better changelog for patch 1, and
another patch at the end to short-circuit kvm_apic_set_base() (not just the inner
helper) if the new value is the same as the old value.

Thanks Kai!

> static int __set_sregs_common(...)
> {
> struct msr_data apic_base_msr;
> ...
>
> apic_base_msr.data = sregs->apic_base;
> apic_base_msr.host_initiated = true;
> if (kvm_set_apic_base(vcpu, &apic_base_msr))
> return -EINVAL;
> ...
> }
>