From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0D3AC432C2 for ; Wed, 25 Sep 2019 13:16:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C742821D56 for ; Wed, 25 Sep 2019 13:16:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406326AbfIYNQA (ORCPT ); Wed, 25 Sep 2019 09:16:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37888 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406302AbfIYNQA (ORCPT ); Wed, 25 Sep 2019 09:16:00 -0400 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 29F72C057867 for ; Wed, 25 Sep 2019 13:16:00 +0000 (UTC) Received: by mail-wr1-f69.google.com with SMTP id t11so2366955wro.10 for ; Wed, 25 Sep 2019 06:16:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=li+RJAZERyAnlpLvPEO2mCJT9+G6j7Ld/SRjBrvxHfc=; b=NoctjGsUowDD4jfKVBU/x2TAbz+aTpN9X8mKoWNATzgYTWrGM1kmkN/6IN3srmRuSx C8AFhBwgCxYTf4Ap21mVLmgJv799wxs3Gvl5h4itwfvmy1G3vY5ZAOFFSy+EV0j0nd1y QlTlYlnHliTeKQ3Bc/wQDxY/1/fErlNY1tax9U867OG6T1x9+8hqjou2jmsTS42/d91F LO/3fUSmSCvVJ8mKLNx35Pacwnmo4lNZeXOgeM68WDImG1L0bXacDKkPziE0Vi5pFZLx 5+2Vh+8a/DyDQ1JjrPhSW8VvmYBtP5MTNSYzBqjqZ+7666fnK2h7SVNNSkcW7ZLSAkg1 UvLQ== X-Gm-Message-State: APjAAAWax6cfFS131HLwW6rXjO1owOGXH55yhoKuRUvdoRxUP6BBJBIH iraPWViIo/7S0VeARa1fhARL5V29bgsw8CMG/MmJQj0UKWkGcsufoFGRxxcyNg3KP8gpZPz9g0B 6dXAeKal5P3PC/qoWfsP7WPA2 X-Received: by 2002:a5d:6302:: with SMTP id i2mr10060827wru.249.1569417358003; Wed, 25 Sep 2019 06:15:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqwFI9mAjWpOt1irI66Kj1UbIBIjLaK0zHtCoXzv3fBHCXtZCPMf+523IuWV+vq98Z0jwtHItA== X-Received: by 2002:a5d:6302:: with SMTP id i2mr10060604wru.249.1569417355789; Wed, 25 Sep 2019 06:15:55 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:9520:22e6:6416:5c36? ([2001:b07:6468:f312:9520:22e6:6416:5c36]) by smtp.gmail.com with ESMTPSA id x5sm9112207wrg.69.2019.09.25.06.15.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Sep 2019 06:15:55 -0700 (PDT) Subject: Re: [PATCH] KVM: selftests: fix ucall on x86 To: Vitaly Kuznetsov , kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Sean Christopherson , Jim Mattson , Thomas Huth , Andrew Jones , Cornelia Huck References: <20190925131242.29986-1-vkuznets@redhat.com> From: Paolo Bonzini Openpgp: preference=signencrypt Message-ID: <7151fc11-b434-1114-cbd0-023b0b8ca6d3@redhat.com> Date: Wed, 25 Sep 2019 15:15:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190925131242.29986-1-vkuznets@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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