[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALMp9eTG8CbWZaDumKsBsr0qQgrre-_=Fn5jzs7GqHB+MZ-E_A@mail.gmail.com>
Date: Tue, 7 Nov 2023 11:59:35 -0800
From: Jim Mattson <jmattson@...gle.com>
To: isaku.yamahata@...el.com
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
isaku.yamahata@...il.com, Paolo Bonzini <pbonzini@...hat.com>,
erdemaktas@...gle.com, Sean Christopherson <seanjc@...gle.com>,
Vishal Annapurve <vannapurve@...gle.com>
Subject: Re: [PATCH 2/2] KVM: X86: Add a capability to configure bus frequency
for APIC timer
On Tue, Nov 7, 2023 at 11:24 AM <isaku.yamahata@...el.com> wrote:
>
> From: Isaku Yamahata <isaku.yamahata@...el.com>
>
> 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@google.com/
> Reported-by: Vishal Annapurve <vannapurve@...gle.com>
> Signed-off-by: Isaku Yamahata <isaku.yamahata@...el.com>
> ---
> 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
>
>
Powered by blists - more mailing lists