All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: paul@xen.org, Fred Griffoul <fgriffo@amazon.co.uk>, kvm@vger.kernel.org
Cc: Sean Christopherson <seanjc@google.com>,
	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>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Update Xen-specific CPUID leaves during mangling
Date: Wed, 22 Jan 2025 18:44:40 +0100	[thread overview]
Message-ID: <87r04u7ng7.fsf@redhat.com> (raw)
In-Reply-To: <a5d69c3b-5b9f-4ecf-bae2-2110e52eac64@xen.org>

Paul Durrant <xadimgnik@gmail.com> writes:

> On 22/01/2025 17:16, Vitaly Kuznetsov wrote:
>> Fred Griffoul <fgriffo@amazon.co.uk> writes:
>> 
>>> Previous commit ee3a5f9e3d9b ("KVM: x86: Do runtime CPUID update before
>>> updating vcpu->arch.cpuid_entries") implemented CPUID data mangling in
>>> KVM_SET_CPUID2 support before verifying that no changes occur on running
>>> vCPUs. However, it overlooked the CPUID leaves that are modified by
>>> KVM's Xen emulation.
>>>
>>> Fix this by calling a Xen update function when mangling CPUID data.
>>>
>>> Fixes: ee3a5f9e3d9b ("KVM: x86: Do runtime CPUID update before
>>> updating vcpu->arch.cpuid_entries")
>> 
>> Well, kvm_xen_update_tsc_info() was added with
>> 
>> commit f422f853af0369be27d2a9f1b20079f2bc3d1ca2
>> Author: Paul Durrant <pdurrant@amazon.com>
>> Date:   Fri Jan 6 10:36:00 2023 +0000
>> 
>>      KVM: x86/xen: update Xen CPUID Leaf 4 (tsc info) sub-leaves, if present
>> 
>> and the commit you mention in 'Fixes' is older:
>> 
>> commit ee3a5f9e3d9bf94159f3cc80da542fbe83502dd8
>> Author: Vitaly Kuznetsov <vkuznets@redhat.com>
>> Date:   Mon Jan 17 16:05:39 2022 +0100
>> 
>>      KVM: x86: Do runtime CPUID update before updating vcpu->arch.cpuid_entries
>> 
>> so I guess we should be 'Fixing' f422f853af03 instead :-)
>> 
>>> Signed-off-by: Fred Griffoul <fgriffo@amazon.co.uk>
>>> ---
>>>   arch/x86/kvm/cpuid.c | 1 +
>>>   arch/x86/kvm/xen.c   | 5 +++++
>>>   arch/x86/kvm/xen.h   | 5 +++++
>>>   3 files changed, 11 insertions(+)
>>>
>>> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
>>> index edef30359c19..432d8e9e1bab 100644
>>> --- a/arch/x86/kvm/cpuid.c
>>> +++ b/arch/x86/kvm/cpuid.c
>>> @@ -212,6 +212,7 @@ static int kvm_cpuid_check_equal(struct kvm_vcpu *vcpu, struct kvm_cpuid_entry2
>>>   	 */
>>>   	kvm_update_cpuid_runtime(vcpu);
>>>   	kvm_apply_cpuid_pv_features_quirk(vcpu);
>>> +	kvm_xen_update_cpuid_runtime(vcpu);
>> 
>> This one is weird as we update it in runtime (kvm_guest_time_update())
>> and values may change when we e.g. migrate the guest. First, I do not
>> understand how the guest is supposed to notice the change as CPUID data
>> is normally considered static. Second, I do not see how the VMM is
>> supposed to track it as if it tries to supply some different data for
>> these Xen leaves, kvm_cpuid_check_equal() will still fail.
>> 
>> Would it make more sense to just ignore these Xen CPUID leaves with TSC
>> information when we do the comparison?
>> 
>
> What is the purpose of the comparison anyway? 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.

-- 
Vitaly


  reply	other threads:[~2025-01-22 17:44 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 [this message]
2025-01-22 18:53       ` David Woodhouse
2025-01-22 22:00         ` Sean Christopherson
2025-01-23 12:35           ` Vitaly Kuznetsov
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=87r04u7ng7.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.