From patchwork Fri Apr 5 22:43:41 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 10887913 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id CE5D417EE for ; Fri, 5 Apr 2019 22:43:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B7D8A285FB for ; Fri, 5 Apr 2019 22:43:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id AC78C286D5; Fri, 5 Apr 2019 22:43:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 56711285FB for ; Fri, 5 Apr 2019 22:43:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726419AbfDEWnx (ORCPT ); Fri, 5 Apr 2019 18:43:53 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:37445 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726360AbfDEWnw (ORCPT ); Fri, 5 Apr 2019 18:43:52 -0400 Received: by mail-wr1-f65.google.com with SMTP id w10so9731772wrm.4 for ; Fri, 05 Apr 2019 15:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references; bh=age8+PuApNF6h/PkMKNNValkrCPv7841BB75aJWwuZ4=; b=dfOXwxM/EKA0AXIn79OKw7XHNkNKhXD2v/3tEpaC9/45Wz6CjWOlwR2ozRzpLa9Gme H3g6oiXTME9o8IuhVTXqKQKYFtYgW08Fq2nMrzvYxvx8Y3E6YBIOLlXgFYcYCmLAJtKG 5Oovt8cLut8XOfiMj6qGQ5G0kO38yrlAimYqdTCKGe5pA/U2yl7fY1dzdnwUdi9sAKTr CUQBvgf3Jn3nG7Agg3x3NYSsoETLVfu3zlenCvJx4/F86Yjgz0uJxnV4/G2cMU0u6ES4 ui72R4xcmECX6S4zr6DByf4nI5uCTxceLVvjD9fpkOTnXP5zL1F6MLKbrDtEL3w/Zsm6 l7eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references; bh=age8+PuApNF6h/PkMKNNValkrCPv7841BB75aJWwuZ4=; b=En5BSdoFJJ5TwVaecJNc4tCXGi4ePZ0MV8qHuySWWC8NGdWjvxMFoHCWXCN9ZzLylQ 0HK7VwDjMazQ2Ttwf7rW1mukelnrY6qtfFDwgMqY4rb2BByPXV/BXAp6zcjL26rM8Fck 8Uzfi4VJQ+lEtjzn8O3wTM856+nUru1plpJYDnrsB8i3d8jUe0lY5UDQBeB6+MRCuYys 7Mkznq1dNMJ/CEC7oLYB4uoFW7Eu7m6VFTBf6opluYwllDsyxEIguBzlWqE3IMEzbA6u EYx1LRgGhLxVBUSodHHjrlzG9Ai65bbcqyciFi/G9bJaXTCmsAE53mW3k85agzP1oQoK xdPQ== X-Gm-Message-State: APjAAAUux+/RJIDj3jyeecFNdSbBl0JDwlGCqTf2VUEK85gNPW3b7VbV StqojI50zZt5LfPGy6w70Tuo2g8c X-Google-Smtp-Source: APXvYqxW5juKzPFzzorJtndK6S3BKOTsgXN5+VyR/gnTJ6TEvjYPDS3dgardMLtWIfUnGlHeNNC6WA== X-Received: by 2002:adf:e74f:: with SMTP id c15mr9715165wrn.23.1554504230225; Fri, 05 Apr 2019 15:43:50 -0700 (PDT) Received: from 640k.lan ([93.56.166.5]) by smtp.gmail.com with ESMTPSA id h2sm42821876wro.11.2019.04.05.15.43.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 15:43:49 -0700 (PDT) From: Paolo Bonzini To: kvm@vger.kernel.org Cc: Marc Orr Subject: [PATCH kvm-unit-tests 4/6] fix vmx_apic_reg_virt for older platforms Date: Sat, 6 Apr 2019 00:43:41 +0200 Message-Id: <1554504223-7919-5-git-send-email-pbonzini@redhat.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1554504223-7919-1-git-send-email-pbonzini@redhat.com> References: <1554504223-7919-1-git-send-email-pbonzini@redhat.com> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Marc Orr This test was failing because "Use TPR shadow" virtualization behaves differently across platforms. For example, on Sandy Bridge the upper three bytes of the VTPR are cleared upon VM entry, whereas they are left as is on Skylake. This difference in behavior is consistent with the SDM, which according to Volume 3, Section 26.2.1.1 VM-Execution Control Fields, says: ... bytes 3:1 of VTPR may be cleared (behavior may be implementation-specific). ... Signed-off-by: Marc Orr Signed-off-by: Paolo Bonzini --- x86/vmx_tests.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/x86/vmx_tests.c b/x86/vmx_tests.c index 092e70e..41c763d 100644 --- a/x86/vmx_tests.c +++ b/x86/vmx_tests.c @@ -5405,6 +5405,7 @@ struct apic_reg_virt_guest_args { u32 reg; u32 val; bool check_rd; + u32 (*virt_fn)(u32); } apic_reg_virt_guest_args; static void apic_reg_virt_guest(void) @@ -5418,6 +5419,7 @@ static void apic_reg_virt_guest(void) u32 reg = args->reg; u32 val = args->val; bool check_rd = args->check_rd; + u32 (*virt_fn)(u32) = args->virt_fn; if (op == TERMINATE) break; @@ -5425,9 +5427,13 @@ static void apic_reg_virt_guest(void) if (op == APIC_OP_XAPIC_RD) { u32 ret = vmx_xapic_read(apic_access_address, reg); - if (check_rd) + if (check_rd) { + u32 want = virt_fn(val); + u32 got = virt_fn(ret); + report("read 0x%x, expected 0x%x.", - ret == val, ret, val); + got == want, got, want); + } } else if (op == APIC_OP_XAPIC_WR) { vmx_xapic_write(apic_access_address, reg, val); } @@ -5457,6 +5463,7 @@ static void test_xapic_rd( args->reg = reg; args->val = val; args->check_rd = exit_reason_want == VMX_VMCALL; + args->virt_fn = expectation->virt_fn; /* Setup virtual APIC page */ if (!expectation->virtualize_apic_accesses) {