On 15/10/2024 8:40 am, Sean Christopherson wrote:
On Mon, Oct 14, 2024, Sean Christopherson wrote:
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,
Duh, because patch 1 doesn't change any of that. KVM already skips setting the
map DIRTY if neither MSR_IA32_APICBASE_ENABLE nor X2APIC_ENABLE is toggled. So
it's really just the (IIRC, rare) collision with an already-dirty map that's nice
to avoid.
I think if the map is already dirty, the other thread that makes the map
dirty must be responsible for calling kvm_recalculate_apic_map() after that.
For updating 'apic_base' path, IIUC it makes sense anyway to avoid
everything when 'apic_base' doesn't change.
Calling kvm_recalculate_apic_map() when 'apic_base' is not changed has
no harm, but logically I don't think there's need to do that, even the
map is already dirty.
