Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp691163ybp; Wed, 9 Oct 2019 02:42:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqxhI/LPbtV4MwlR4pAxZzhvvMIPKsgnK8G3v1vwUL35XJxSf4fiDV3lYVeHUI31kXRbSfF8 X-Received: by 2002:aa7:d045:: with SMTP id n5mr2087250edo.24.1570614172308; Wed, 09 Oct 2019 02:42:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570614172; cv=none; d=google.com; s=arc-20160816; b=OsS73Sl/p548ZdQY0GkMNYIeqF+8a0BUCze61naEDllTI+qI6GBje1VofdM23Wvidx AxQCkC6rdGuzJM+cQAnBaJYsZL20v/RlQ4pR+DzPzY2WLTR9rMpIke9gQnX95TwXcub/ /MszxGibUz8Vl27k54uyNTNTj2u+R4dfuqhZj96tSbpjBlG/QHqhBYd0FNYV6J/rHY57 aDeXuaVHYcHrjYYnSFoWUs/wAwI39IR4ZiXRnCTtU4ks6QRQBViqMP+yI4X/+kfNkFYy /6ZQ4Ur9WguGRnaZkEnCibNieNGI5KZoA4cQ7G12VnLgX9A3zNKEuiENpyyfXnGG9qHH xBWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:openpgp:from:references:cc:to:subject; bh=2SfK+bwB/cF2Z8hlX+aReQdgBCXk+L/5n2wFayhP4Gk=; b=ro2bl94K5+1rNt9jj5QvbQLMtTMcNUCfuizkVgGJ8DWh9XVv/sDoCpOHCNz+qFtrD/ 2jCv6NKkeQzhZOx9KY39ykv8Rna6VFaRk3xRHqgWlbaQlnamAFnZRlitUxWNK3UyU1q1 7LKiNoQ/XS7pqjim8tdC4mOWnxaCnLOyP8HjDpj1RUo2AXHgkRbcmDgj2UhRDqsdN1Zt s/O8SOBV+eMiptPW6Kw3cz1040ZT+qAb1uucK+IjtcEeOVyWYb4jFQdMPG/xxX53i2A1 8/AVtd11ipvkPvp04f2LkGgJS9keNSX6z+ObsBluaoDr5meq1/YUv3QulB8+e/C+q+Os Hb5A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k23si954772ede.274.2019.10.09.02.42.28; Wed, 09 Oct 2019 02:42:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730059AbfJIJmU (ORCPT + 99 others); Wed, 9 Oct 2019 05:42:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45200 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728200AbfJIJmU (ORCPT ); Wed, 9 Oct 2019 05:42:20 -0400 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (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 CAC48859FE for ; Wed, 9 Oct 2019 09:42:19 +0000 (UTC) Received: by mail-wm1-f71.google.com with SMTP id q9so783455wmj.9 for ; Wed, 09 Oct 2019 02:42:19 -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=2SfK+bwB/cF2Z8hlX+aReQdgBCXk+L/5n2wFayhP4Gk=; b=mZamM1iFC/4hrzJrxiH/ahvXukLcx8ml93xgLAjCxpPzaCF7gNsQVBSnIWzJQVv7l5 3siJDfMbIyq0Loq5wtHg9EY6d6ZTzIA6gS1I7A7KcMyrTmHdMVUnXyKfCE+vY8cKjJAm dV+TevoIqCdI/ieBxGi6EMewqCH6aIA0KmdZiyu1OWgNL0PVf7vU73JRKC6zc3C4bPS0 hwGfr/AxBIUDMY1LaSejhpOBAGz67giioBUjVe1fO9arhR5IEN2uahuagVjTm09bmHdy qCUpYLgggWpPlrX975QQq6EOqiSNPQdj8ZKxi9cL4VynZicT736DNuhtfupi+f63QJnu oM4Q== X-Gm-Message-State: APjAAAWgw3A6aKWekGExFaFk0F8Vtaogf75eY8xElO1WpGJlHf+hZIFA jzAT1opgHKCOcx4Las6OtqyKQuQTgePfb3HRfvL2USYH5o7+4RtLZsxk7YmF+obb3hSZbfdoGrB eOgiLkI/QTzS0ZiVwxArwbzk/ X-Received: by 2002:a1c:a8c9:: with SMTP id r192mr1857215wme.152.1570614138036; Wed, 09 Oct 2019 02:42:18 -0700 (PDT) X-Received: by 2002:a1c:a8c9:: with SMTP id r192mr1857192wme.152.1570614137681; Wed, 09 Oct 2019 02:42:17 -0700 (PDT) Received: from [192.168.10.150] ([93.56.166.5]) by smtp.gmail.com with ESMTPSA id c9sm1607213wrt.7.2019.10.09.02.42.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Oct 2019 02:42:17 -0700 (PDT) Subject: Re: [PATCH] selftests: kvm: fix sync_regs_test with newer gccs To: Sean Christopherson , Vitaly Kuznetsov Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jim Mattson References: <20191008180808.14181-1-vkuznets@redhat.com> <20191008183634.GF14020@linux.intel.com> From: Paolo Bonzini Openpgp: preference=signencrypt Message-ID: Date: Wed, 9 Oct 2019 11:42:12 +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: <20191008183634.GF14020@linux.intel.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 08/10/19 20:36, Sean Christopherson wrote: > On Tue, Oct 08, 2019 at 08:08:08PM +0200, Vitaly Kuznetsov wrote: >> Commit 204c91eff798a ("KVM: selftests: do not blindly clobber registers in >> guest asm") was intended to make test more gcc-proof, however, the result >> is exactly the opposite: on newer gccs (e.g. 8.2.1) the test breaks with >> >> ==== Test Assertion Failure ==== >> x86_64/sync_regs_test.c:168: run->s.regs.regs.rbx == 0xBAD1DEA + 1 >> pid=14170 tid=14170 - Invalid argument >> 1 0x00000000004015b3: main at sync_regs_test.c:166 (discriminator 6) >> 2 0x00007f413fb66412: ?? ??:0 >> 3 0x000000000040191d: _start at ??:? >> rbx sync regs value incorrect 0x1. >> >> Apparently, compile is still free to play games with registers even >> when they have variables attaches. >> >> Re-write guest code with 'asm volatile' by embedding ucall there and >> making sure rbx is preserved. >> >> Fixes: 204c91eff798a ("KVM: selftests: do not blindly clobber registers in guest asm") >> Signed-off-by: Vitaly Kuznetsov >> --- >> .../selftests/kvm/x86_64/sync_regs_test.c | 21 ++++++++++--------- >> 1 file changed, 11 insertions(+), 10 deletions(-) >> >> diff --git a/tools/testing/selftests/kvm/x86_64/sync_regs_test.c b/tools/testing/selftests/kvm/x86_64/sync_regs_test.c >> index 11c2a70a7b87..5c8224256294 100644 >> --- a/tools/testing/selftests/kvm/x86_64/sync_regs_test.c >> +++ b/tools/testing/selftests/kvm/x86_64/sync_regs_test.c >> @@ -22,18 +22,19 @@ >> >> #define VCPU_ID 5 >> >> +#define UCALL_PIO_PORT ((uint16_t)0x1000) >> + >> +/* >> + * ucall is embedded here to protect against compiler reshuffling registers >> + * before calling a function. In this test we only need to get KVM_EXIT_IO >> + * vmexit and preserve RBX, no additional information is needed. >> + */ >> void guest_code(void) >> { >> - /* >> - * use a callee-save register, otherwise the compiler >> - * saves it around the call to GUEST_SYNC. >> - */ >> - register u32 stage asm("rbx"); >> - for (;;) { >> - GUEST_SYNC(0); >> - stage++; >> - asm volatile ("" : : "r" (stage)); >> - } >> + asm volatile("1: in %[port], %%al\n" >> + "add $0x1, %%rbx\n" >> + "jmp 1b" >> + : : [port] "d" (UCALL_PIO_PORT) : "rax", "rbx"); >> } > > To make the code truly bulletproof, is it possible to rename guest_code() > to guest_code_wrapper() and then export 1: as guest_code? VM-Enter will > jump directly to the relevant code and gcc can't touch rbx. E.g.: > > asm volatile("1: ..." > ".global guest_code" > "guest_code: " _ASM_PTR " 1b"); > > Not sure if that works with how the selftests are compiled. It may also > be possible to simply replace '1' with 'guest_code'. There is no practical difference with Vitaly's patch. The first _vcpu_run has no pre-/post-conditions on the value of %rbx: run->kvm_valid_regs = TEST_SYNC_FIELDS; rv = _vcpu_run(vm, VCPU_ID); TEST_ASSERT(run->exit_reason == KVM_EXIT_IO, "Unexpected exit reason: %u (%s),\n", run->exit_reason, exit_reason_str(run->exit_reason)); /* * Then it goes on comparing regs/sregs/events, but does not * check for specific values. */ As soon as that first _vcpu_run succeeds, you're stuck in the in/add/jmp loop and the compiler can't trick you anymore. So, I'm queuing the patch. Paolo