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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 5A621C47247 for ; Tue, 5 May 2020 18:10:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 33115206FA for ; Tue, 5 May 2020 18:10:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588702256; bh=WdYkPZE/293zR7WzWCJ4+neg7BG9vBaeaHBO/vgMctM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=AzjYzWwjCDz8Wr75W59Cv6QR+byc10X5F2ze/xmqD9OODMq5WVsGf/98C0uzJ0DfA YJ9XWtm+UhZpvShsrfQtkf92qQTNwPfasqGPXSP+c6mWS0MYQIFRO/cOVf/1Qo4r++ Ui07siZ8sVVa4K1//3R/wxNa2IpxePdqTQP7D4lk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730760AbgEESKz (ORCPT ); Tue, 5 May 2020 14:10:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:57232 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729315AbgEESKy (ORCPT ); Tue, 5 May 2020 14:10:54 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 12B5E206B8; Tue, 5 May 2020 18:10:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588702254; bh=WdYkPZE/293zR7WzWCJ4+neg7BG9vBaeaHBO/vgMctM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sHyv4DFdRAGLwvbTYAEY4V1bXwK+vPKh9sipsbL84Y4hMGam/3M8YtASvMiCl0AVl wHZ1re5z2AUaFNJ/VaoF3BOBDMvuJLyL3rRhkPxzCyAlksTiTTL2q+VQgQsOiNKyy2 Dk/cTgxeuUDvN6C2yp568EEUlruh8txqehJem42Q= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=big-swifty.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jW21s-009bV3-3P; Tue, 05 May 2020 19:10:52 +0100 Date: Tue, 05 May 2020 19:10:50 +0100 Message-ID: <86mu6mtfpx.wl-maz@kernel.org> From: Marc Zyngier To: Andrew Scull Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Will Deacon , Andre Przywara , Dave Martin , George Cherian , "Zengtao (B)" , Catalin Marinas Subject: Re: [PATCH 03/26] KVM: arm64: Factor out stage 2 page table data from struct kvm In-Reply-To: <20200505172351.GD237572@google.com> References: <20200422120050.3693593-1-maz@kernel.org> <20200422120050.3693593-4-maz@kernel.org> <20200505152648.GA237572@google.com> <86pnbitka5.wl-maz@kernel.org> <20200505172351.GD237572@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: ascull@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, will@kernel.org, andre.przywara@arm.com, Dave.Martin@arm.com, gcherian@marvell.com, prime.zeng@hisilicon.com, catalin.marinas@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 05 May 2020 18:23:51 +0100, Andrew Scull wrote: > > > > > + /* VTCR_EL2 value for this VM */ > > > > + u64 vtcr; > > > > > > VTCR seems quite strongly tied to the MMU config. Is it not controlled > > > independently for the nested MMUs and so remains in this struct? > > > > This particular instance of VTCR_EL2 is the host's version. Which > > means it describes the virtual HW for the EL1 guest. It constraints, > > among other things, the number of IPA bits for the guest, for example, > > and is configured by the VMM. > > > > Once you start nesting, each vcpu has its own VTCR_EL2 which is still > > constrained by the main one (no nested guest can have a T0SZ bigger > > than the value imposed by userspace for this guest as a whole). > > > > Does it make sense? > > It does up to my ignorance of the spec in this regard. > > Simliar to James's question, should `vtcr` live inside the mmu struct > with the top level `kvm::mmu` field containing the host's version and > the nested mmus containing the nested version of vtcr to be applied to > the vCPU? I didn't noticed there being a vtcr for the nested version in > the ~90-patch series so maybe that just isn't something that needs > thinking about? They serve two very different purposes. One defines the virtual HW, the other one is the view that a guest hypervisor gives to its own guests. The latter is also per-vcpu, and not per VM (yes, NV implies the "de-facto CnP", for those who remember an intense whiteboard session). It thus lives in the system register file (being private to each vcpu). Another reason is that the HW can directly access the in-memory version of VTCR_EL2 when ARMv8.4-NV is present. Thanks, M. -- Jazz is not dead, it just smells funny.