mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jürgen Groß" <jgross@suse.com>
To: Borislav Petkov <bp@alien8.de>
Cc: xen-devel@lists.xenproject.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, peterz@infradead.org,
	luto@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v2 07/12] x86: add new features for paravirt patching
Date: Wed, 9 Dec 2020 08:30:53 +0100	[thread overview]
Message-ID: <2510752e-5d3d-f71c-8a4c-a5d2aae0075e@suse.com> (raw)
In-Reply-To: <20201208184315.GE27920@zn.tnic>


[-- Attachment #1.1.1: Type: text/plain, Size: 5320 bytes --]

On 08.12.20 19:43, Borislav Petkov wrote:
> On Fri, Nov 20, 2020 at 12:46:25PM +0100, Juergen Gross wrote:
>> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
>> index dad350d42ecf..ffa23c655412 100644
>> --- a/arch/x86/include/asm/cpufeatures.h
>> +++ b/arch/x86/include/asm/cpufeatures.h
>> @@ -237,6 +237,9 @@
>>   #define X86_FEATURE_VMCALL		( 8*32+18) /* "" Hypervisor supports the VMCALL instruction */
>>   #define X86_FEATURE_VMW_VMMCALL		( 8*32+19) /* "" VMware prefers VMMCALL hypercall instruction */
>>   #define X86_FEATURE_SEV_ES		( 8*32+20) /* AMD Secure Encrypted Virtualization - Encrypted State */
>> +#define X86_FEATURE_NOT_XENPV		( 8*32+21) /* "" Inverse of X86_FEATURE_XENPV */
>> +#define X86_FEATURE_NO_PVUNLOCK		( 8*32+22) /* "" No PV unlock function */
>> +#define X86_FEATURE_NO_VCPUPREEMPT	( 8*32+23) /* "" No PV vcpu_is_preempted function */
> 
> Ew, negative features. ;-\

Hey, I already suggested to use ~FEATURE for that purpose (see
https://lore.kernel.org/lkml/f105a63d-6b51-3afb-83e0-e899ea40813e@suse.com/ 
).

> 
> /me goes forward and looks at usage sites:
> 
> +	ALTERNATIVE_2 "jmp *paravirt_iret(%rip);",			\
> +		      "jmp native_iret;", X86_FEATURE_NOT_XENPV,	\
> +		      "jmp xen_iret;", X86_FEATURE_XENPV
> 
> Can we make that:
> 
> 	ALTERNATIVE_TERNARY "jmp *paravirt_iret(%rip);",
> 		      "jmp xen_iret;", X86_FEATURE_XENPV,
> 		      "jmp native_iret;", X86_FEATURE_XENPV,

Would we really want to specify the feature twice?

I'd rather make the syntax:

ALTERNATIVE_TERNARY <initial-code> <feature> <code-for-feature-set>
                                              <code-for-feature-unset>

as this ...

> 
> where the last two lines are supposed to mean
> 
> 			    X86_FEATURE_XENPV ? "jmp xen_iret;" : "jmp native_iret;"

... would match perfectly to this interpretation.

> 
> Now, in order to convey that logic to apply_alternatives(), you can do:
> 
> struct alt_instr {
>          s32 instr_offset;       /* original instruction */
>          s32 repl_offset;        /* offset to replacement instruction */
>          u16 cpuid;              /* cpuid bit set for replacement */
>          u8  instrlen;           /* length of original instruction */
>          u8  replacementlen;     /* length of new instruction */
>          u8  padlen;             /* length of build-time padding */
> 	u8  flags;		/* patching flags */ 			<--- THIS
> } __packed;

Hmm, using flags is an alternative (pun intended :-) ).

> 
> and yes, we have had the flags thing in a lot of WIP diffs over the
> years but we've never come to actually needing it.
> 
> Anyway, then, apply_alternatives() will do:
> 
> 	if (flags & ALT_NOT_FEATURE)
> 
> or something like that - I'm bad at naming stuff - then it should patch
> only when the feature is NOT set and vice versa.
> 
> There in that
> 
> 	if (!boot_cpu_has(a->cpuid)) {
> 
> branch.
> 
> Hmm?

Fine with me (I'd prefer my ALTERNATIVE_TERNARY syntax, though).

> 
>>   /* Intel-defined CPU features, CPUID level 0x00000007:0 (EBX), word 9 */
>>   #define X86_FEATURE_FSGSBASE		( 9*32+ 0) /* RDFSBASE, WRFSBASE, RDGSBASE, WRGSBASE instructions*/
>> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
>> index 2400ad62f330..f8f9700719cf 100644
>> --- a/arch/x86/kernel/alternative.c
>> +++ b/arch/x86/kernel/alternative.c
>> @@ -593,6 +593,18 @@ int alternatives_text_reserved(void *start, void *end)
>>   #endif /* CONFIG_SMP */
>>   
>>   #ifdef CONFIG_PARAVIRT
>> +static void __init paravirt_set_cap(void)
>> +{
>> +	if (!boot_cpu_has(X86_FEATURE_XENPV))
>> +		setup_force_cpu_cap(X86_FEATURE_NOT_XENPV);
>> +
>> +	if (pv_is_native_spin_unlock())
>> +		setup_force_cpu_cap(X86_FEATURE_NO_PVUNLOCK);
>> +
>> +	if (pv_is_native_vcpu_is_preempted())
>> +		setup_force_cpu_cap(X86_FEATURE_NO_VCPUPREEMPT);
>> +}
>> +
>>   void __init_or_module apply_paravirt(struct paravirt_patch_site *start,
>>   				     struct paravirt_patch_site *end)
>>   {
>> @@ -616,6 +628,8 @@ void __init_or_module apply_paravirt(struct paravirt_patch_site *start,
>>   }
>>   extern struct paravirt_patch_site __start_parainstructions[],
>>   	__stop_parainstructions[];
>> +#else
>> +static void __init paravirt_set_cap(void) { }
>>   #endif	/* CONFIG_PARAVIRT */
>>   
>>   /*
>> @@ -723,6 +737,18 @@ void __init alternative_instructions(void)
>>   	 * patching.
>>   	 */
>>   
>> +	paravirt_set_cap();
> 
> Can that be called from somewhere in the Xen init path and not from
> here? Somewhere before check_bugs() gets called.

No, this is needed for non-Xen cases, too (especially pv spinlocks).

> 
>> +	/*
>> +	 * First patch paravirt functions, such that we overwrite the indirect
>> +	 * call with the direct call.
>> +	 */
>> +	apply_paravirt(__parainstructions, __parainstructions_end);
>> +
>> +	/*
>> +	 * Then patch alternatives, such that those paravirt calls that are in
>> +	 * alternatives can be overwritten by their immediate fragments.
>> +	 */
>>   	apply_alternatives(__alt_instructions, __alt_instructions_end);
> 
> Can you give an example here pls why the paravirt patching needs to run
> first?

Okay.


Juergen

[-- Attachment #1.1.2: OpenPGP_0xB0DE9DD628BF132F.asc --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

  reply	other threads:[~2020-12-09  7:32 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20 11:46 [PATCH v2 00/12] x86: major paravirt cleanup Juergen Gross
2020-11-20 11:46 ` [PATCH v2 01/12] x86/xen: use specific Xen pv interrupt entry for MCE Juergen Gross
2020-12-09 21:03   ` Thomas Gleixner
2020-11-20 11:46 ` [PATCH v2 02/12] x86/xen: use specific Xen pv interrupt entry for DF Juergen Gross
2020-12-09 21:03   ` Thomas Gleixner
2020-11-20 11:46 ` [PATCH v2 03/12] x86/pv: switch SWAPGS to ALTERNATIVE Juergen Gross
2020-11-27 11:31   ` Borislav Petkov
2020-12-09 21:07   ` Thomas Gleixner
2020-11-20 11:46 ` [PATCH v2 04/12] x86/xen: drop USERGS_SYSRET64 paravirt call Juergen Gross
2020-12-02 12:32   ` Borislav Petkov
2020-12-02 14:48     ` Jürgen Groß
2020-12-02 17:08       ` Borislav Petkov
2020-11-20 11:46 ` [PATCH v2 05/12] x86: rework arch_local_irq_restore() to not use popf Juergen Gross
2020-11-20 11:59   ` Peter Zijlstra
2020-11-20 12:05     ` Jürgen Groß
2020-11-22  6:55     ` Jürgen Groß
2020-11-22 21:44       ` Andy Lutomirski
2020-11-23  5:21         ` Jürgen Groß
2020-11-23 15:15           ` Andy Lutomirski
2020-12-09 13:27         ` Mark Rutland
2020-12-09 14:02           ` Mark Rutland
2020-12-09 14:05             ` Jürgen Groß
2020-12-09 18:15     ` Mark Rutland
2020-12-09 18:54       ` Thomas Gleixner
2020-12-10 11:10         ` Mark Rutland
2020-12-10 20:15           ` x86/ioapic: Cleanup the timer_works() irqflags mess Thomas Gleixner
2020-12-10 22:04             ` [tip: x86/apic] " tip-bot2 for Thomas Gleixner
2020-12-11  5:10             ` Jürgen Groß
2020-11-27  2:20   ` [x86] 97e8f0134a: fio.write_iops 8.6% improvement kernel test robot
2020-11-20 11:46 ` [PATCH v2 06/12] x86/paravirt: switch time pvops functions to use static_call() Juergen Gross
2020-11-20 12:01   ` Peter Zijlstra
2020-11-20 12:07     ` Jürgen Groß
2020-11-20 11:46 ` [PATCH v2 07/12] x86: add new features for paravirt patching Juergen Gross
2020-12-08 18:43   ` Borislav Petkov
2020-12-09  7:30     ` Jürgen Groß [this message]
2020-12-09 12:03       ` Borislav Petkov
2020-12-09 12:22         ` Jürgen Groß
2020-12-10 17:58           ` Borislav Petkov
2020-11-20 11:46 ` [PATCH v2 08/12] x86/paravirt: remove no longer needed 32-bit pvops cruft Juergen Gross
2020-11-20 12:08   ` Peter Zijlstra
2020-11-20 12:16     ` Jürgen Groß
2020-11-20 16:52   ` Arvind Sankar
2020-11-20 11:46 ` [PATCH v2 09/12] x86/paravirt: switch iret pvops to ALTERNATIVE Juergen Gross
2020-11-20 11:46 ` [PATCH v2 10/12] x86/paravirt: add new macros PVOP_ALT* supporting pvops in ALTERNATIVEs Juergen Gross
2020-11-20 11:46 ` [PATCH v2 11/12] x86/paravirt: switch functions with custom code to ALTERNATIVE Juergen Gross
2020-11-20 15:46   ` kernel test robot
2020-11-25 15:46   ` [x86/paravirt] fd8d46a7a2: kernel-selftests.livepatch.test-callbacks.sh.fail kernel test robot
2020-11-20 11:46 ` [PATCH v2 12/12] x86/paravirt: have only one paravirt patch function Juergen Gross
2020-11-20 14:18   ` kernel test robot
2020-11-20 12:53 ` [PATCH v2 00/12] x86: major paravirt cleanup Peter Zijlstra
2020-11-23 13:43   ` Peter Zijlstra
2020-12-15 11:42     ` Jürgen Groß
2020-12-15 14:18       ` Peter Zijlstra
2020-12-15 14:54         ` Peter Zijlstra
2020-12-15 15:07           ` Jürgen Groß
2020-12-16  0:38           ` Josh Poimboeuf
2020-12-16  8:40             ` Peter Zijlstra
2020-12-16 16:56               ` Josh Poimboeuf
2020-12-16 17:58                 ` Peter Zijlstra

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=2510752e-5d3d-f71c-8a4c-a5d2aae0075e@suse.com \
    --to=jgross@suse.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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 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®