[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f25105910970164234b2ab046f8dbacc7f7a4992.camel@infradead.org>
Date: Thu, 23 Jan 2025 08:44:22 -0800
From: David Woodhouse <dwmw2@...radead.org>
To: Vitaly Kuznetsov <vkuznets@...hat.com>, Sean Christopherson
<seanjc@...gle.com>
Cc: paul@....org, Fred Griffoul <fgriffo@...zon.co.uk>, kvm@...r.kernel.org,
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>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: x86: Update Xen-specific CPUID leaves during
mangling
On Thu, 2025-01-23 at 13:35 +0100, Vitaly Kuznetsov wrote:
>
> I guess we can change the logic the following: when KVM_SET_CPUID2 is
> called on a vCPU again we check that all entries which KVM did not touch
> match. For that, we will need to keep a list of mangled entries so we
> can introduce a kvm_mangle_cpuid_entry() helper to avoid the need to
> keep a static list. Personally, I'm not sure this is not an overkill
> though.
Putting that another way, KVM would exempt the dynamic entries that KVM
is going to overwrite by *itself*, from the comparison. By keeping a
list of the entries that it's going to overwrite.
I'm not sure I'd call that overkill. I think I prefer it to the option
of mangling the CPUID at *runtime* in kvm_cpuid() while the entries in
the array differ from what the guest actually sees.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)
Powered by blists - more mailing lists