diff mbox

x86emul: correct stub invocation constraints again

Message ID 5901CAE30200007800154B17@prv-mh.provo.novell.com (mailing list archive)
State New, archived
Headers show

Commit Message

Jan Beulich April 27, 2017, 8:41 a.m. UTC
While the hypervisor side of commit cd91ab08ea ("x86emul: correct stub
invocation constraints") was fine, the tools side triggered a bogus
error with old gcc (4.3 and 4.4 at least). Use a slightly less
appropriate variant instead, proven to be good enough to not
re-introduce the original problem: Which of the addresses is actually
used doesn't matter much as long as the compiler can't prove that the
two pointers don't alias one another.

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
x86emul: correct stub invocation constraints again

While the hypervisor side of commit cd91ab08ea ("x86emul: correct stub
invocation constraints") was fine, the tools side triggered a bogus
error with old gcc (4.3 and 4.4 at least). Use a slightly less
appropriate variant instead, proven to be good enough to not
re-introduce the original problem: Which of the addresses is actually
used doesn't matter much as long as the compiler can't prove that the
two pointers don't alias one another.

Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -901,7 +901,7 @@ do{ asm volatile (
 # define invoke_stub(pre, post, constraints...)                         \
     asm volatile ( pre "\n\tcall *%[stub]\n\t" post                     \
                    : constraints, [stub] "rm" (stub.func),              \
-                     "m" (*(uint8_t(*)[MAX_INST_LEN + 1])stub.buf) )
+                     "m" (*(typeof(stub.buf) *)stub.addr) )
 #endif
 
 #define emulate_stub(dst, src...) do {                                  \

Comments

Andrew Cooper April 27, 2017, 8:43 a.m. UTC | #1
On 27/04/2017 09:41, Jan Beulich wrote:
> While the hypervisor side of commit cd91ab08ea ("x86emul: correct stub
> invocation constraints") was fine, the tools side triggered a bogus
> error with old gcc (4.3 and 4.4 at least). Use a slightly less
> appropriate variant instead, proven to be good enough to not
> re-introduce the original problem: Which of the addresses is actually
> used doesn't matter much as long as the compiler can't prove that the
> two pointers don't alias one another.
>
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Boris Ostrovsky April 27, 2017, 1:51 p.m. UTC | #2
On 04/27/2017 04:41 AM, Jan Beulich wrote:
> While the hypervisor side of commit cd91ab08ea ("x86emul: correct stub
> invocation constraints") was fine, the tools side triggered a bogus
> error with old gcc (4.3 and 4.4 at least). Use a slightly less
> appropriate variant instead, proven to be good enough to not
> re-introduce the original problem: Which of the addresses is actually
> used doesn't matter much as long as the compiler can't prove that the
> two pointers don't alias one another.
>
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -901,7 +901,7 @@ do{ asm volatile (
>  # define invoke_stub(pre, post, constraints...)                         \
>      asm volatile ( pre "\n\tcall *%[stub]\n\t" post                     \
>                     : constraints, [stub] "rm" (stub.func),              \
> -                     "m" (*(uint8_t(*)[MAX_INST_LEN + 1])stub.buf) )
> +                     "m" (*(typeof(stub.buf) *)stub.addr) )
>  #endif
>  
>  #define emulate_stub(dst, src...) do {                                  \

Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>


And to answer your earlier question --- this was tools-specific (but you
already know this now).

-boris
Ian Jackson April 28, 2017, 1:59 p.m. UTC | #3
Jan Beulich writes ("[PATCH] x86emul: correct stub invocation constraints again"):
> While the hypervisor side of commit cd91ab08ea ("x86emul: correct stub
> invocation constraints") was fine, the tools side triggered a bogus
> error with old gcc (4.3 and 4.4 at least). Use a slightly less
> appropriate variant instead, proven to be good enough to not
> re-introduce the original problem: Which of the addresses is actually
> used doesn't matter much as long as the compiler can't prove that the
> two pointers don't alias one another.
> 
> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Release-acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
diff mbox

Patch

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -901,7 +901,7 @@  do{ asm volatile (
 # define invoke_stub(pre, post, constraints...)                         \
     asm volatile ( pre "\n\tcall *%[stub]\n\t" post                     \
                    : constraints, [stub] "rm" (stub.func),              \
-                     "m" (*(uint8_t(*)[MAX_INST_LEN + 1])stub.buf) )
+                     "m" (*(typeof(stub.buf) *)stub.addr) )
 #endif
 
 #define emulate_stub(dst, src...) do {                                  \