From: Paolo Bonzini <pbonzini@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>, kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
"Dāvis Mosāns" <davispuh@gmail.com>
Subject: Re: [PATCH] KVM: nSVM: fix nested tsc scaling when not enabled but MSR_AMD64_TSC_RATIO set
Date: Mon, 21 Feb 2022 14:22:19 +0100 [thread overview]
Message-ID: <76493240-46c4-61d1-8ce5-a4c5f6c1ecb8@redhat.com> (raw)
In-Reply-To: <263fc33973fa6cea8001bddceed1f69153db5174.camel@redhat.com>
On 2/21/22 14:17, Maxim Levitsky wrote:
>> It's not clear how QEMU ends up writing MSR_AMD64_TSC_RATIO_DEFAULT
>> rather than 0, but we clearly have a bug in KVM. It should not allow
>> writing 0 in the first place if tsc-ratio is not available in the VM.
>
> Qemu currently (the code is very new so it can be changed) writes the initial value of
> 0 to this msr if tsc scaling is disabled in the guest, or MSR_AMD64_TSC_RATIO_DEFAULT
> if the tsc scaling is enabled.
It's released in 6.2, though, right?
> The guest can change it only when TSC scaling is enabled for it.
> If tsc scaling is not enabled, both guest reads or writes of this MSR get #GP.
> I only allowed qemu writes of this msr because I thought that qemu might
> first set the MSR and then set guest CPUID.
>
> Also, for example the MSR_IA32_XSS uses the same logic in KVM.
>
> As for why qemu sets this msr regardless of guest CPUID bit,
> it seemed to be cleaner this way - kvm_put_msrs in qemu seems not to
> check guest CPUID but rather only check that KVM supports this msr,
> which will be true regardless of guest's CPUID bit.
Yes, I agree it's cleaner in QEMU and consistent with others in KVM.
However the value that is written should be the default one (which is
usually zero, but not always and not in this case).
Paolo
prev parent reply other threads:[~2022-02-21 13:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0a0b61c5c071415f213a4704ebd73e65761ec1a3.camel@redhat.com>
2022-02-21 10:33 ` Maxim Levitsky
2022-02-21 12:33 ` Paolo Bonzini
2022-02-21 13:17 ` Maxim Levitsky
2022-02-21 13:22 ` Paolo Bonzini [this message]
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=76493240-46c4-61d1-8ce5-a4c5f6c1ecb8@redhat.com \
--to=pbonzini@redhat.com \
--cc=davispuh@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=stable@vger.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
all inboxes | Powered by JetHome®