On Tue, Nov 7, 2023 at 11:24 AM <isaku.yamahata@xxxxxxxxx> wrote: > > From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx> > > Add KVM_CAP_X86_BUS_FREQUENCY_CONTROL capability to configure the core > crystal clock (or processor's bus clock) for APIC timer emulation. Allow > KVM_ENABLE_CAPABILITY(KVM_CAP_X86_BUS_FREUQNCY_CONTROL) to set the Nit: FREQUENCY > frequency. When using this capability, the user space VMM should configure > CPUID[0x15] to advertise the frequency. Is it necessary to advertise the frequency in CPUID.15H? No hardware that I know of has a 1 GHz crystal clock, but the current implementation works fine without CPUID.15H. > TDX virtualizes CPUID[0x15] for the core crystal clock to be 25MHz. The > x86 KVM hardcodes its freuqncy for APIC timer to be 1GHz. This mismatch Nit: frequency > causes the vAPIC timer to fire earlier than the guest expects. [1] The KVM > APIC timer emulation uses hrtimer, whose unit is nanosecond. Make the > parameter configurable for conversion from the TMICT value to nanosecond. > > This patch doesn't affect the TSC deadline timer emulation. The TSC > deadline emulation path records its expiring TSC value and calculates the > expiring time in nanoseconds. The APIC timer emulation path calculates the > TSC value from the TMICT register value and uses the TSC deadline timer > path. This patch touches the APIC timer-specific code but doesn't touch > common logic. > > [1] https://lore.kernel.org/lkml/20231006011255.4163884-1-vannapurve@xxxxxxxxxx/ > Reported-by: Vishal Annapurve <vannapurve@xxxxxxxxxx> > Signed-off-by: Isaku Yamahata <isaku.yamahata@xxxxxxxxx> > --- > arch/x86/kvm/x86.c | 14 ++++++++++++++ > include/uapi/linux/kvm.h | 1 + > 2 files changed, 15 insertions(+) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index a9f4991b3e2e..20849d2cd0e8 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -4625,6 +4625,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) > case KVM_CAP_ENABLE_CAP: > case KVM_CAP_VM_DISABLE_NX_HUGE_PAGES: > case KVM_CAP_IRQFD_RESAMPLE: > + case KVM_CAP_X86_BUS_FREQUENCY_CONTROL: This capability should be documented in Documentation/virtual/kvm/api.txt. > r = 1; > break; > case KVM_CAP_EXIT_HYPERCALL: > @@ -6616,6 +6617,19 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > } > mutex_unlock(&kvm->lock); > break; > + case KVM_CAP_X86_BUS_FREQUENCY_CONTROL: { > + u64 bus_frequency = cap->args[0]; > + u64 bus_cycle_ns; > + To avoid potentially bizarre behavior, perhaps we should disallow changing the APIC bus frequency once a vCPU has been created? > + if (!bus_frequency) > + return -EINVAL; > + bus_cycle_ns = 1000000000UL / bus_frequency; > + if (!bus_cycle_ns) > + return -EINVAL; > + kvm->arch.apic_bus_cycle_ns = bus_cycle_ns; > + kvm->arch.apic_bus_frequency = bus_frequency; > + return 0; Should this be disallowed if !lapic_in_kernel? > + } > default: > r = -EINVAL; > break; > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 211b86de35ac..d74a057df173 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -1201,6 +1201,7 @@ struct kvm_ppc_resize_hpt { > #define KVM_CAP_ARM_EAGER_SPLIT_CHUNK_SIZE 228 > #define KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES 229 > #define KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES 230 > +#define KVM_CAP_X86_BUS_FREQUENCY_CONTROL 231 > > #ifdef KVM_CAP_IRQ_ROUTING > > -- > 2.25.1 > >
