[PATCH] KVM: selftests: fix ucall on x86

[PATCH] KVM: selftests: fix ucall on x86

[Vitaly Kuznetsov]

After commit e8bb4755eea2("KVM: selftests: Split ucall.c into architecture
specific files") selftests which use ucall on x86 started segfaulting and
apparently it's gcc to blame: it "optimizes" ucall() function throwing away
va_start/va_end part because it thinks the structure is not being used.
Previously, it couldn't do that because the there was also MMIO version and
the decision which particular implementation to use was done at runtime.

With older gccs it's possible to solve the problem by adding 'volatile'
to 'struct ucall' but at least with gcc-8.3 this trick doesn't work.

'memory' clobber seems to do the job.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
s390 should, in theory, have the same problem. Thomas, Cornelia, could
you please take a look? Thanks!
---
 tools/testing/selftests/kvm/lib/x86_64/ucall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/kvm/lib/x86_64/ucall.c b/tools/testing/selftests/kvm/lib/x86_64/ucall.c
index 4bfc9a90b1de..da4d89ad5419 100644
--- a/tools/testing/selftests/kvm/lib/x86_64/ucall.c
+++ b/tools/testing/selftests/kvm/lib/x86_64/ucall.c
@@ -32,7 +32,7 @@ void ucall(uint64_t cmd, int nargs, ...)
 	va_end(va);
 
 	asm volatile("in %[port], %%al"
-		: : [port] "d" (UCALL_PIO_PORT), "D" (&uc) : "rax");
+		: : [port] "d" (UCALL_PIO_PORT), "D" (&uc) : "rax", "memory");
 }
 
 uint64_t get_ucall(struct kvm_vm *vm, uint32_t vcpu_id, struct ucall *uc)
-- 
2.20.1

Re: [PATCH] KVM: selftests: fix ucall on x86

[Paolo Bonzini]

On 25/09/19 15:12, Vitaly Kuznetsov wrote:
> After commit e8bb4755eea2("KVM: selftests: Split ucall.c into architecture
> specific files") selftests which use ucall on x86 started segfaulting and
> apparently it's gcc to blame: it "optimizes" ucall() function throwing away
> va_start/va_end part because it thinks the structure is not being used.
> Previously, it couldn't do that because the there was also MMIO version and
> the decision which particular implementation to use was done at runtime.
> 
> With older gccs it's possible to solve the problem by adding 'volatile'
> to 'struct ucall' but at least with gcc-8.3 this trick doesn't work.
> 
> 'memory' clobber seems to do the job.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> s390 should, in theory, have the same problem. Thomas, Cornelia, could
> you please take a look? Thanks!
> ---
>  tools/testing/selftests/kvm/lib/x86_64/ucall.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/kvm/lib/x86_64/ucall.c b/tools/testing/selftests/kvm/lib/x86_64/ucall.c
> index 4bfc9a90b1de..da4d89ad5419 100644
> --- a/tools/testing/selftests/kvm/lib/x86_64/ucall.c
> +++ b/tools/testing/selftests/kvm/lib/x86_64/ucall.c
> @@ -32,7 +32,7 @@ void ucall(uint64_t cmd, int nargs, ...)
>  	va_end(va);
>  
>  	asm volatile("in %[port], %%al"
> -		: : [port] "d" (UCALL_PIO_PORT), "D" (&uc) : "rax");
> +		: : [port] "d" (UCALL_PIO_PORT), "D" (&uc) : "rax", "memory");
>  }
>  
>  uint64_t get_ucall(struct kvm_vm *vm, uint32_t vcpu_id, struct ucall *uc)
> 

Queued, thanks.  s390 already clobbers memory.

Paolo