From: Xin Li <xin@zytor.com>
To: Sean Christopherson <seanjc@google.com>,
Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Binbin Wu <binbin.wu@linux.intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH v3 4/6] KVM: x86: Add support for RDMSR/WRMSRNS w/ immediate on Intel
Date: Tue, 2 Sep 2025 08:46:42 -0700 [thread overview]
Message-ID: <c28069c2-4a28-4803-89e1-9056514196a0@zytor.com> (raw)
In-Reply-To: <aLcEMCMDRCEZnmdH@google.com>
On 9/2/2025 7:50 AM, Sean Christopherson wrote:
> On Mon, Sep 01, 2025, Xiaoyao Li wrote:
>> On 9/1/2025 3:04 PM, Xin Li wrote:
>>> On 8/31/2025 11:34 PM, Binbin Wu wrote:
>>>>> We need to inject #UD for !guest_cpu_has(X86_FEATURE_MSR_IMM)
>>>>>
>>>>
>>>> Indeed.
>>>
>>> Good catch!
>>>
>>>>
>>>> There is a virtualization hole of this feature for the accesses to the
>>>> MSRs not intercepted. IIUIC, there is no other control in VMX for this
>>>> feature. If the feature is supported in hardware, the guest will succeed
>>>> when it accesses to the MSRs not intercepted even when the feature is not
>>>> exposed to the guest, but the guest will get #UD when access to the MSRs
>>>> intercepted if KVM injects #UD.
>>>
>>> hpa mentioned this when I just started the work. But I managed to forget
>>> it later... Sigh!
>>>
>>>>
>>>> But I guess this is the guest's fault by not following the CPUID,
>>>> KVM should
>>>> still follow the spec?
>>>
>>> I think we should still inject #UD when a MSR is intercepted by KVM.
>
> Hmm, no, inconsistent behavior (from the guest's perspective) is likely worse
> than eating with the virtualization hole. Practically speaking, the only guest
> that's going to be surprised by the hole is a guest that's fuzzing opcodes, and
> a guest that's fuzzing opcodes at CPL0 isn't is going to create an inherently
> unstable environment no matter what.
Hmm, a malicious guest could *smartly* avoid causing such vmexits. So more
or less that is wasteful and no objection here.
>
> Though that raises the question of whether or not KVM should emulate WRMSRNS and
> whatever the official name for the "RDMSR with immediate" instruction is (I can't
> find it in the SDM). I'm leaning "no", because outside of forced emulation, KVM
> should only "need" to emulate the instructions if Unrestricted Guest is disabled,
> the instructions should only be supported on CPUs with unrestricted guest, there's
> no sane reason (other than testing) to run a guest without Unrestricted Guest,
> and using the instructions in Big RM would be quite bizarre. On the other hand,
> adding emulation support should be quite easy...
>
> Side topic, does RDMSRLIST have any VMX controls?
Yes, bit 6 of Tertiary Processor-Based VM-Execution Controls, below is C&P
from Intel SDM:
Enable MSR-list instructions control: if this control is 0, any execution
of RDMSRLIST or WRMSRLIST causes a #UD.
If the control is 1, the instruction commences normally, writing one MSR at
a time. Writes to certain MSRs are treated specially as described above for
WRMSR and WRMSRNS. In addition, attempts to access specific MSRs may cause
VM exits.
For RDMSRLIST and WRMSRLIST, the exit qualification depends on the setting
of the “use MSR bitmaps” VM-execution control. If the control is 0, the
exit qualification is zero. If the control is 1, the exit qualification
is the index of the MSR whose access caused the VM exit.
next prev parent reply other threads:[~2025-09-02 15:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-05 20:22 [PATCH v3 0/6] KVM: VMX: Handle the immediate form of MSR instructions Sean Christopherson
2025-08-05 20:22 ` [PATCH v3 1/6] x86/cpufeatures: Add a CPU feature bit for MSR immediate form instructions Sean Christopherson
2025-08-05 20:22 ` [PATCH v3 2/6] KVM: x86: Rename local "ecx" variables to "msr" and "pmc" as appropriate Sean Christopherson
2025-08-06 15:42 ` Xin Li
2025-08-05 20:22 ` [PATCH v3 3/6] KVM: x86: Rename handle_fastpath_set_msr_irqoff() to handle_fastpath_wrmsr() Sean Christopherson
2025-08-06 15:48 ` Xin Li
2025-08-05 20:22 ` [PATCH v3 4/6] KVM: x86: Add support for RDMSR/WRMSRNS w/ immediate on Intel Sean Christopherson
2025-09-01 4:13 ` Xiaoyao Li
2025-09-01 6:34 ` Binbin Wu
2025-09-01 7:04 ` Xin Li
2025-09-01 7:22 ` Xiaoyao Li
2025-09-02 14:50 ` Sean Christopherson
2025-09-02 15:46 ` Xin Li [this message]
2025-09-03 4:43 ` Xiaoyao Li
2025-09-18 18:33 ` Sean Christopherson
2025-08-05 20:22 ` [PATCH v3 5/6] KVM: VMX: Support the immediate form of WRMSRNS in the VM-Exit fastpath Sean Christopherson
2025-08-05 20:22 ` [PATCH v3 6/6] KVM: x86: Advertise support for the immediate form of MSR instructions Sean Christopherson
2025-08-06 15:38 ` [PATCH v3 0/6] KVM: VMX: Handle " Xin Li
2025-08-19 23:12 ` Sean Christopherson
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=c28069c2-4a28-4803-89e1-9056514196a0@zytor.com \
--to=xin@zytor.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=xiaoyao.li@intel.com \
/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®