From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Sean Christopherson <seanjc@google.com>,
David Woodhouse <dwmw2@infradead.org>
Cc: paul@xen.org, Fred Griffoul <fgriffo@amazon.co.uk>,
kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Update Xen-specific CPUID leaves during mangling
Date: Thu, 23 Jan 2025 13:35:17 +0100 [thread overview]
Message-ID: <87ldv17loa.fsf@redhat.com> (raw)
In-Reply-To: <Z5FqdjTwPmnV1t-1@google.com>
Sean Christopherson <seanjc@google.com> writes:
> On Wed, Jan 22, 2025, David Woodhouse wrote:
>> On Wed, 2025-01-22 at 18:44 +0100, Vitaly Kuznetsov wrote:
>> > > What is the purpose of the comparison anyway?
>
> To avoid scenarios where KVM has configured state for a set of features X, and
> doesn't correctly handle vCPU features suddenly become Y. Or more commonly,
> where correctly handling such transitions (if there's even a "correct" option)
> is a complete waste of time and complexity because no sane setup will ever add
> and/or remove features from a running VM.
>
>> > > IIUC we want to ensure that a VMM does not change its mind after KVM_RUN
>> > > so should we not be stashing what was set by the VMM and comparing
>> > > against that *before* mangling any values?
>> >
>> > I guess it can be done this way but we will need to keep these 'original'
>> > unmangled values for the lifetime of the vCPU with very little gain (IMO):
>> > KVM_SET_CPUID{,2} either fails (if the data is different) or does (almost)
>> > nothing when the data is the same.
>
> More importantly, userspace is allowed to set the CPUID returned by KVM_GET_CPUID2.
> E.g. selftests do KVM_GET_CPUID2 specifically to read the bits that are managed
> by KVM.
>
> Disallowing that would likely break userspace, and would create a weird ABI where
> the output of KVM_GET_CPUID2 is rejected by KVM_SET_CPUID2.
>
>> If they're supposed to be entirely unchanged, would it suffice just to
>> keep a hash of them?
In case we want to support both cases:
- VMM calls KVM_SET_CPUID2 at some point in vCPU's lifetime with the
same data it used initially;
- VMM does KVM_GET_CPUID2 and feeds this directly into KVM_SET_CPUID2
we can't use a hash as the later contains entries mangled by
KVM. Currently, we kind of support both but we expect the result of the
mangling done by KVM to always be the same.
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.
--
Vitaly
next prev parent reply other threads:[~2025-01-23 12:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-22 16:16 [PATCH] KVM: x86: Update Xen-specific CPUID leaves during mangling Fred Griffoul
2025-01-22 17:16 ` Vitaly Kuznetsov
2025-01-22 17:19 ` Paul Durrant
2025-01-22 17:44 ` Vitaly Kuznetsov
2025-01-22 18:53 ` David Woodhouse
2025-01-22 22:00 ` Sean Christopherson
2025-01-23 12:35 ` Vitaly Kuznetsov [this message]
2025-01-23 16:44 ` David Woodhouse
2025-01-23 1:13 ` Sean Christopherson
2025-01-23 13:24 ` Vitaly Kuznetsov
2025-01-23 15:33 ` Griffoul, Fred
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ldv17loa.fsf@redhat.com \
--to=vkuznets@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dwmw2@infradead.org \
--cc=fgriffo@amazon.co.uk \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox