From: Xin Li <xin@zytor.com>
To: "H. Peter Anvin" <hpa@zytor.com>, "Jürgen Groß" <jgross@suse.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
virtualization@lists.linux.dev,
"Peter Zijlstra" <peterz@infradead.org>
Cc: Ajay Kaher <ajay.kaher@broadcom.com>,
Alexey Makhalov <alexey.amakhalov@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to instruction interfaces
Date: Thu, 15 May 2025 00:32:40 -0700 [thread overview]
Message-ID: <652dfd63-e41c-4d7a-8fea-40509e8191ef@zytor.com> (raw)
In-Reply-To: <DDA7C560-1BD9-40A6-8B93-28D5AC10EBB2@zytor.com>
On 5/13/2025 3:24 PM, H. Peter Anvin wrote:
> On May 12, 2025 11:06:02 PM PDT, "Jürgen Groß" <jgross@suse.com> wrote:
>> On 13.05.25 07:55, Xin Li wrote:
>>> On 5/12/2025 4:24 AM, Juergen Gross wrote:
>>>> Now with the mentioned patch really attached. :-)
>>>>
>>>
>>> Does it allow patching with an instruction more than 6 bytes long?
>>>
>>> The immediate form MSR instructions are 9 bytes long.
>>
>> Yes, shouldn't be a problem.
>>
>>
>> Juergen
>
> However, it is more than that. The immediate instructions have a different interface, and it makes more sense to use the extra bytes to shuffle the bits around for the legacy forms:
>
> Write:
>
> mov %rax,%rdx
> shr $32,%rdx
> wrmsr(ns)
>
> Read:
>
> rdmsr
> shl $32,%rdx
> or %rdx,%rax
>
> For the write case, this also means that two separate trap points are needed.
>
> As far as Xen (the only user of pv msrs), note that it only paravirtualizes a very small number of MSRs, and some of those are fairly performance sensitive, so not going through the Xen framework for MSRs known to be either native or null on Xen would definitely be a win.
>
>
Hi Juergen,
I have some update on this thread while working on it.
If we continue down the path of maintaining pvops MSR APIs as this patch
series does, it seems we’ll need to duplicate the ALTERNATIVE code in
three different places.
1) The MSR access primitives defined in <asm/msr.h>, which is used when
CONFIG_PARAVIRT=n.
2) The pvops native MSR functions pv_native_{rd,wr}msr{,_safe}() defined
in arch/x86/kernel/paravirt.c, used when CONFIG_PARAVIRT=y on bare
metal.
3) The pvops Xen MSR functions paravirt_{read,write}_msr{,_safe}()
defined in <asm/paravirt.h>, used when CONFIG_PARAVIRT_XXL=y.
hpa had mentioned to me earlier that this would be a maintenance burden
— something I only truly realized once I got hands-on with it.
Maybe you have something in mind to address it?
Also add PeterZ to the To list because he cares it.
Thanks!
Xin
next prev parent reply other threads:[~2025-05-15 7:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 9:20 [PATCH 0/6] x86/msr: let paravirt inline rdmsr/wrmsr instructions Juergen Gross
2025-05-06 9:20 ` [PATCH 1/6] coco/tdx: Rename MSR access helpers Juergen Gross
2025-05-06 11:26 ` Kirill A. Shutemov
2025-05-06 9:20 ` [PATCH 2/6] x86/kvm: Rename the KVM private read_msr() function Juergen Gross
2025-05-06 13:53 ` Sean Christopherson
2025-05-06 13:58 ` Jürgen Groß
2025-05-06 16:16 ` Ingo Molnar
2025-05-06 16:29 ` H. Peter Anvin
2025-05-06 9:20 ` [PATCH 3/6] x86/msr: minimize usage of native_*() msr access functions Juergen Gross
2025-05-06 14:24 ` Sean Christopherson
2025-05-09 21:49 ` Wei Liu
2025-05-06 9:20 ` [PATCH 4/6] x86/msr: Move MSR trace calls one function level up Juergen Gross
2025-05-06 9:20 ` [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to instruction interfaces Juergen Gross
2025-05-09 8:18 ` Xin Li
2025-05-12 11:20 ` Jürgen Groß
2025-05-12 11:24 ` Juergen Gross
2025-05-13 5:55 ` Xin Li
2025-05-13 6:06 ` Jürgen Groß
2025-05-13 6:55 ` Xin Li
2025-05-13 22:24 ` H. Peter Anvin
2025-05-15 7:32 ` Xin Li [this message]
2025-05-15 20:24 ` H. Peter Anvin
2025-05-13 7:44 ` Xin Li
2025-06-11 12:58 ` Juergen Gross
2025-06-13 7:31 ` Xin Li
2025-06-13 8:01 ` Jürgen Groß
2025-08-25 1:54 ` Xin Li
2025-08-26 10:39 ` Jürgen Groß
2025-09-29 11:07 ` Juergen Gross
2025-05-06 9:20 ` [PATCH 6/6] x86/msr: reduce number of low level MSR access helpers Juergen Gross
2025-05-10 16:03 ` [PATCH 0/6] x86/msr: let paravirt inline rdmsr/wrmsr instructions Michael Kelley
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=652dfd63-e41c-4d7a-8fea-40509e8191ef@zytor.com \
--to=xin@zytor.com \
--cc=ajay.kaher@broadcom.com \
--cc=alexey.amakhalov@broadcom.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux.dev \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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.