All of lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Casasnovas <quentin.casasnovas@oracle.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>,
	X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Oleg Nesterov <oleg@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH] x86/xsave: Robustify and merge macros
Date: Sat, 4 Apr 2015 10:36:11 +0200	[thread overview]
Message-ID: <20150404083611.GA5922@chrystal.uk.oracle.com> (raw)
In-Reply-To: <20150404073454.GA21152@pd.tnic>

On Sat, Apr 04, 2015 at 09:34:54AM +0200, Borislav Petkov wrote:
> On Fri, Apr 03, 2015 at 10:42:17PM +0200, Quentin Casasnovas wrote:
> > If you're happy with the extra padding in such cases then your second
> > approach looks okay to me.  But IMO, even if taking the '.if' directive
> > approach is certainly bigger LOC-wise, it should be much easier to review
> > in a rush than some other .skip trickery.
> 
> .if needs absolute expressions and I can't get it to even compile with the
> experiments I've done so far.
> 
> How about this instead?
> 
> It basically computes the padding length by doing
> 
> max(len(repl1), len(repl2)) - len(orig)
>

Nice!

> and without conditionals. The macros all do string expansion so that the
> strings can get parsed by gas. Initial smoke testing in kvm seems to
> work, I need to test it on real metal:
>
> ---
> diff --git a/arch/x86/include/asm/alternative-asm.h b/arch/x86/include/asm/alternative-asm.h
> index 524bddce0b76..44a1fc5439d3 100644
> --- a/arch/x86/include/asm/alternative-asm.h
> +++ b/arch/x86/include/asm/alternative-asm.h
> @@ -45,12 +45,22 @@
>  	.popsection
>  .endm
>  
> +#define old_len			141b-140b
> +#define new_len1		144f-143f
> +#define new_len2		145f-144f
> +
> +/*
> + * Shamelessly stolen and adapted from:
> + * http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax
> + */
> +#define alt_max_short(a,b)	(((a) - (((a) - (b)) & (((a) - (b)) >> 15))) & 0xffff)
> +

Since all of these are compile time constants, could we not use the safe
variant on that same page?  Not that I'm too worried about the signed right
shift but heh that would be portable and should not impact performance
anyway, so no added value in using the optimized version is there?

>  .macro ALTERNATIVE_2 oldinstr, newinstr1, feature1, newinstr2, feature2
>  140:
>  	\oldinstr
>  141:
> -	.skip -(((144f-143f)-(141b-140b)) > 0) * ((144f-143f)-(141b-140b)),0x90
> -	.skip -(((145f-144f)-(144f-143f)-(141b-140b)) > 0) * ((145f-144f)-(144f-143f)-(141b-140b)),0x90
> +	.skip -((alt_max_short(new_len1, new_len2) - old_len) > 0) * \
> +		(alt_max_short(new_len1, new_len2) - old_len),0x90
>  142:
>  
>  	.pushsection .altinstructions,"a"
> diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
> index 5aef6a97d80e..2c515ebcc767 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -96,13 +96,19 @@ static inline int alternatives_text_reserved(void *start, void *end)
>  	alt_end_marker ":\n"
>  
>  /*
> + * max without conditionals. Shamelessly stolen and adapted from:
> + * http://graphics.stanford.edu/~seander/bithacks.html#IntegerMinOrMax
> + */
> +#define alt_max_short(a, b)	"(((" a ") - (((" a ") - (" b ")) & (((" a ") - (" b ")) >> 15))) & 0xffff)"
> +
> +/*
>   * Pad the second replacement alternative with additional NOPs if it is
>   * additionally longer than the first replacement alternative.
>   */
> -#define OLDINSTR_2(oldinstr, num1, num2)					\
> -	__OLDINSTR(oldinstr, num1)						\
> -	".skip -(((" alt_rlen(num2) ")-(" alt_rlen(num1) ")-(662b-661b)) > 0) * " \
> -		"((" alt_rlen(num2) ")-(" alt_rlen(num1) ")-(662b-661b)),0x90\n"  \
> +#define OLDINSTR_2(oldinstr, num1, num2) \
> +	"661:\n\t" oldinstr "\n662:\n"								\
> +	".skip -((" alt_max_short(alt_rlen(num1), alt_rlen(num2)) " - (" alt_slen ")) > 0) * "	\
> +		"(" alt_max_short(alt_rlen(num1), alt_rlen(num2)) " - (" alt_slen ")), 0x90\n"	\
>  	alt_end_marker ":\n"

On the bonus side, you're getting rid of the double 'alt_end_marker' label
in case of an alternative_2()!

Looks good to me and I find it much easier to understand here :)

Thanks,
Quentin

  reply	other threads:[~2015-04-04  8:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-02 13:11 [PATCH] x86/xsave: Robustify and merge macros Borislav Petkov
2015-04-02 15:52 ` Quentin Casasnovas
2015-04-02 16:12   ` Borislav Petkov
2015-04-02 16:33     ` Quentin Casasnovas
2015-04-02 16:45       ` Borislav Petkov
2015-04-03 14:06     ` Quentin Casasnovas
2015-04-03 14:14       ` Quentin Casasnovas
2015-04-03 15:23         ` Borislav Petkov
2015-04-03 15:40           ` Quentin Casasnovas
2015-04-03 17:06             ` Borislav Petkov
2015-04-03 17:33               ` Quentin Casasnovas
2015-04-03 17:48                 ` Borislav Petkov
2015-04-03 20:42                   ` Quentin Casasnovas
2015-04-04  7:34                     ` Borislav Petkov
2015-04-04  8:36                       ` Quentin Casasnovas [this message]
2015-04-04  9:25                         ` Borislav Petkov
2015-04-04 10:11                           ` Quentin Casasnovas
2015-04-04 10:29                             ` Borislav Petkov
2015-04-04 13:32                               ` Borislav Petkov
2015-04-04 13:34                                 ` [PATCH] x86/alternatives: Fix ALTERNATIVE_2 padding generation properly Borislav Petkov
2015-04-07  9:27                                   ` Quentin Casasnovas
2015-04-07  9:40                                   ` [tip:x86/asm] " tip-bot for Borislav Petkov

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=20150404083611.GA5922@chrystal.uk.oracle.com \
    --to=quentin.casasnovas@oracle.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@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 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.