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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E77DBC4167B for ; Fri, 9 Dec 2022 20:46:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hjxfUneVjekeyDy8Fgn8Fqx8tsKfr2CriQOpdYJD1+U=; b=nK44Fw1l6E+NE5 Nq8RFEzp5uR+Uqffa8kGk0mdBLva7X1lUG3p2n4VdBzpHWN4qrCBEXg7TC22UsMNSWSfbaBaLLObd xTqnP4Uzy4EINqtgvAtxNpKTAb4Wn3R3r4zsNhaG/fBTsMC8YysxKaBMyTSCxJmbrHfsgr6LdnKfV /rTUbe3XFomJFHnT+wodKBlzpurs5mNyRftFDWwntoC2qYirEBhU09SvI+ybROaAXAA+mqBpMrzjc grx6UM4q4UZ/g0cJElb9zFE1MjiBkWtqIBxutSWXQL7mUwkfi9QpxhRd4asMqbQJw6vgPMV7MEv8+ +6ydRtcEuShx5TbSNhrw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p3kF8-00BBbc-Qd; Fri, 09 Dec 2022 20:45:14 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p3kF5-00BBXI-J4 for linux-arm-kernel@lists.infradead.org; Fri, 09 Dec 2022 20:45:12 +0000 Received: by mail-pj1-x1029.google.com with SMTP id w4-20020a17090ac98400b002186f5d7a4cso9387348pjt.0 for ; Fri, 09 Dec 2022 12:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=vrO0N2BhoytOAhhhHfUhdN91u6TruVaipT5ISV1vaYc=; b=f95FMmTEKSCikEYcOfIHQeZ11wft/M7xtxOLWqo9ddBFll+PEIhNuP8Altnit2pg7l zyRhiE+JRDfj5dB8/WxDXf1drX13fZ1eOh7rba0AIhbehJO0Y9D2Isb+V0FtO1vE8xtB hYMCbXb+6k8JyDHQhnThQvX/+T5zbEXkZxYWQBSqRWCBdOVJmssGwx1Y5IXZJw/6XRzs S3ZdcDYHIQuWdKlJwLHVsg5FbzwD0u0eYrShli67IQw7Q2mlLjgxmxsG0ncnWSJMMZVg KepJ3JyFSc3873pExBYAY27kO9Gx8PluA0Mbdjh+rOeLvfI90C98illSL1VVYvLRtJsW Xzfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vrO0N2BhoytOAhhhHfUhdN91u6TruVaipT5ISV1vaYc=; b=CUF+pH0GwbFV6o0Ucxekj1WoVRL3LQZ+peRziXdmD91de/hcjIhG+FFmcsVpVTPjQm mW+yoHbcvV9/iQBZZmYhJCylmIpn8IGEGSDqaYDl2VXRosym76+WpbjMlTp0ftD2BXKF +aQTCTdtrxvG4azDMhwiXcFctfViBsempStLwMHLltFtCpa7xRc6qC/tEO1S/33+u939 ADurHPckb5ELpy0QT6Pdw6gmmwHc+01kJ8TgNEuzSaO9h2PjBLQLabVDIHSBzXN8DkxF Ft7uaf6GDf3c7/ifigseRcQ5ZcHMLYW1PhZnzed8YICIr8N072zQCOc/Krif1LwBh5dv B5nQ== X-Gm-Message-State: ANoB5plBXRCdxDQaHASHw4a5QwNtEOXHJUu/to41TSPvq1FAoCink2+W EHkPx7BrcRz5rETAZKMJFz6/Qw== X-Google-Smtp-Source: AA0mqf5qINBTPYAP4qeg1UzaZ6wwLAd0BwvCi3JbF60z/oyrT5V6BtufJ7TAxCe0PKR19lvup9WOtA== X-Received: by 2002:a05:6a20:baa3:b0:9d:c38f:9bdd with SMTP id fb35-20020a056a20baa300b0009dc38f9bddmr20370pzb.2.1670618705014; Fri, 09 Dec 2022 12:45:05 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y10-20020aa793ca000000b0057555d35f79sm1614631pff.101.2022.12.09.12.45.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Dec 2022 12:45:04 -0800 (PST) Date: Fri, 9 Dec 2022 20:45:01 +0000 From: Sean Christopherson To: Oliver Upton Cc: Marc Zyngier , James Morse , Alexandru Elisei , Paolo Bonzini , Shuah Khan , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, kvmarm@lists.linux.dev, Ricardo Koller , linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 4/7] KVM: selftests: Correctly initialize the VA space for TTBR0_EL1 Message-ID: References: <20221209015307.1781352-1-oliver.upton@linux.dev> <20221209015307.1781352-5-oliver.upton@linux.dev> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221209015307.1781352-5-oliver.upton@linux.dev> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221209_124511_669495_D9FE0931 X-CRM114-Status: GOOD ( 21.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Dec 09, 2022, Oliver Upton wrote: > An interesting feature of the Arm architecture is that the stage-1 MMU > supports two distinct VA regions, controlled by TTBR{0,1}_EL1. As KVM > selftests on arm64 only uses TTBR0_EL1, the VA space is constrained to > [0, 2^(va_bits)). This is different from other architectures that > allow for addressing low and high regions of the VA space from a single > page table. > > KVM selftests' VA space allocator presumes the valid address range is > split between low and high memory based the MSB, which of course is a > poor match for arm64's TTBR0 region. > > Add a helper that correctly handles both addressing schemes with a > comment describing each. > > Signed-off-by: Oliver Upton > --- Thanks much! Looks awesome, especially the comment! Reviewed-by: Sean Christopherson > .../selftests/kvm/include/kvm_util_base.h | 1 + > tools/testing/selftests/kvm/lib/kvm_util.c | 49 ++++++++++++++++--- > 2 files changed, 44 insertions(+), 6 deletions(-) > > diff --git a/tools/testing/selftests/kvm/include/kvm_util_base.h b/tools/testing/selftests/kvm/include/kvm_util_base.h > index 6cd86da698b3..b193863d754f 100644 > --- a/tools/testing/selftests/kvm/include/kvm_util_base.h > +++ b/tools/testing/selftests/kvm/include/kvm_util_base.h > @@ -103,6 +103,7 @@ struct kvm_vm { > struct sparsebit *vpages_mapped; > bool has_irqchip; > bool pgd_created; > + bool has_split_va_space; > vm_paddr_t ucall_mmio_addr; > vm_paddr_t pgd; > vm_vaddr_t gdt; > diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c > index a256ec67aff6..53d15f32f220 100644 > --- a/tools/testing/selftests/kvm/lib/kvm_util.c > +++ b/tools/testing/selftests/kvm/lib/kvm_util.c > @@ -186,6 +186,43 @@ const struct vm_guest_mode_params vm_guest_mode_params[] = { > _Static_assert(sizeof(vm_guest_mode_params)/sizeof(struct vm_guest_mode_params) == NUM_VM_MODES, > "Missing new mode params?"); > > +/* > + * Initializes vm->vpages_valid to match the canonical VA space of the > + * architecture. > + * > + * Most architectures split the range addressed by a single page table into a > + * low and high region based on the MSB of the VA. On architectures with this > + * behavior the VA region spans [0, 2^(va_bits - 1)), [-(2^(va_bits - 1), -1]. > + * > + * arm64 is a bit different from the rest of the crowd, as the low and high > + * regions of the VA space are addressed by distinct paging structures > + * (TTBR{0,1}_EL1). Oooh, they're different CR3s in x86 terminology? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel