From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH kvm-unit-tests] vmx: fixes for MAXPHYADDR requirement Date: Thu, 25 Jan 2018 16:11:32 +0100 Message-ID: <20180125151132.GB19884@flask> References: <1516212225-37393-2-git-send-email-pbonzini@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39540 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751374AbeAYPLl (ORCPT ); Thu, 25 Jan 2018 10:11:41 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5E03E78232 for ; Thu, 25 Jan 2018 15:11:41 +0000 (UTC) Content-Disposition: inline In-Reply-To: <1516212225-37393-2-git-send-email-pbonzini@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2018-01-17 19:03+0100, Paolo Bonzini: > The EPT access tests require at least 41 bits of guest physical address > space. This is because the test data needs a separate PML4 entry in the > EPT table. However, many consumer-grade processors have only 36 or > 39-bit MAXPHYADDR, and the tests fail there with a page fault due to > reserved bits set in the guest (GVA->GPA) page tables. > > Add a test on MAXPHYADDR and skip the tests if they cannot run on the > system under test, and only require 40 bits to lower the requirements. > > Signed-off-by: Paolo Bonzini > --- > x86/vmx_tests.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/x86/vmx_tests.c b/x86/vmx_tests.c > index e8c97f2..0c3b5a7 100644 > --- a/x86/vmx_tests.c > +++ b/x86/vmx_tests.c > @@ -2609,6 +2609,10 @@ static void ept_access_test_setup(void) > if (setup_ept(false)) > test_skip("EPT not supported"); > > + /* We use data->gpa = 1 << 39 so that test data has a separate pml4 entry */ > + if (cpuid_maxphyaddr() < 40) This does not help at the moment -- QEMU reports 40 even on hosts that don't have as much. It is a QEMU bug, so applied still, thanks.