Re: [PATCH 1/7] x86, asmlinkage, lguest: Pass in globals into assembler statement

[Rusty Russell]

Andi Kleen <andi@xxxxxxxxxxxxxx> writes:
> From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
>
> Tell the compiler that the inline assembler statement
> references lguest_entry.
>
> This fixes compile problems with LTO where the variable
> and the assembler code may end up in different files.
>
> Cc: x86@xxxxxxxxxx
> Cc: rusty@xxxxxxxxxxxxxxx
> Signed-off-by: Andi Kleen <ak@xxxxxxxxxxxxxxx>

Great, thanks.  Might as well keep this with the others:

Acked-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Tested-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx>

Cheers,
Rusty.

> ---
>  drivers/lguest/x86/core.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
> index 5169239..922a1ac 100644
> --- a/drivers/lguest/x86/core.c
> +++ b/drivers/lguest/x86/core.c
> @@ -157,7 +157,7 @@ static void run_guest_once(struct lg_cpu *cpu, struct lguest_pages *pages)
>  	 * stack, then the address of this call.  This stack layout happens to
>  	 * exactly match the stack layout created by an interrupt...
>  	 */
> -	asm volatile("pushf; lcall *lguest_entry"
> +	asm volatile("pushf; lcall *%4"
>  		     /*
>  		      * This is how we tell GCC that %eax ("a") and %ebx ("b")
>  		      * are changed by this routine.  The "=" means output.
> @@ -169,7 +169,9 @@ static void run_guest_once(struct lg_cpu *cpu, struct lguest_pages *pages)
>  		      * physical address of the Guest's top-level page
>  		      * directory.
>  		      */
> -		     : "0"(pages), "1"(__pa(cpu->lg->pgdirs[cpu->cpu_pgd].pgdir))
> +		     : "0"(pages), 
> +		       "1"(__pa(cpu->lg->pgdirs[cpu->cpu_pgd].pgdir)),
> +		       "m"(lguest_entry)
>  		     /*
>  		      * We tell gcc that all these registers could change,
>  		      * which means we don't have to save and restore them in
> -- 
> 1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/