[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ca6c68f-16a7-402f-adb0-327583695d4a@zytor.com>
Date: Tue, 30 Sep 2025 12:59:11 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Jürgen Groß <jgross@...e.com>,
Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
virtualization@...ts.linux.dev, xin@...or.com,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ajay Kaher <ajay.kaher@...adcom.com>,
Alexey Makhalov <alexey.makhalov@...adcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
xen-devel@...ts.xenproject.org
Subject: Re: [PATCH v2 11/12] x86/paravirt: Don't use pv_ops vector for MSR
access functions
On 2025-09-30 12:49, H. Peter Anvin wrote:
>
> /* Xen code, stub sets CF = 1 on failure */
>
> 0: e8 xx xx xx xx call asm_xen_pv_wrmsr
> 5: 73 03 jnc 0xa
> 7: 0f 0b ud2
> 9: 90 nop
> a:
>
> The trap point even ends up in the same place! UD2 can be any 1-, 2-, or
> 3-byte trapping instruction.
>
You can, of course, also simply have a conditional jump, at the expense of
making the whole alternative block one byte longer:
0: e8 xx xx xx xx call asm_xen_pv_wrmsr
5: 0f 82 xx xx xx xx jc wrmsr_failed
-hpa
Powered by blists - more mailing lists