[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c7b494d34d3e14531337311c286a9c06a99c9295.camel@infradead.org>
Date: Thu, 23 Jan 2025 12:32:27 -0800
From: David Woodhouse <dwmw2@...radead.org>
To: Fred Griffoul <fgriffo@...zon.co.uk>, kvm@...r.kernel.org
Cc: griffoul@...il.com, vkuznets@...hat.com, Sean Christopherson
<seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>, Thomas Gleixner
<tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
<bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, Paul Durrant <paul@....org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: Update Xen TSC leaves during CPUID emulation
On Thu, 2025-01-23 at 19:02 +0000, Fred Griffoul wrote:
> +static inline void kvm_xen_may_update_tsc_info(struct kvm_vcpu *vcpu,
> + u32 function, u32 index,
> + u32 *eax, u32 *ecx, u32 *edx)
Should this be called kvm_xen_maybe_update_tsc_info() ?
Is it worth adding if (static_branch_unlikely(&kvm_xen_enabled.key))?
> +{
> + u32 base = vcpu->arch.xen.cpuid.base;
> +
> + if (base && (function == (base | XEN_CPUID_LEAF(3)))) {
> + if (index == 1) {
> + *ecx = vcpu->arch.hv_clock.tsc_to_system_mul;
> + *edx = vcpu->arch.hv_clock.tsc_shift;
Are these fields in vcpu->arch.hv_clock definitely going to be set? If
so, can we have a comment to that effect? And perhaps a warning to
assert the truth of that claim?
Before this patch, if the hv_clock isn't yet set then the guest would
see the original content of the leaves as set by userspace? Now it gets
zeroes if that happens?
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)
Powered by blists - more mailing lists