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=-9.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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 5CBEBC433EF for ; Mon, 6 Sep 2021 09:04:29 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 2914D6103E for ; Mon, 6 Sep 2021 09:04:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2914D6103E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=H6mPPPkdLXcb4exzn/EU6UsP4CXnA1c3jEleFbGCJAc=; b=ufe+kIDQPvDDxy ooC5Dprean2rdPAMvOwnbFOuvzfTAjm+Q+KiQHQx3NwY3Yche7KAi+C7G+qmc6XSFogMtqsi/76+y mm73DnwbUUcIUqOuMpDzi4WTC+DZQtZubcJ3bH1qnj6sf5P5WxXr8speDcmlWTImAekx8po1p/ZMY xxtTt3UReAR5lx3Kx07oCXLmgAJjyd5YX23d+EeGYmOst4mH5Arv7+vn4QfyF8WN6DNrF4EI2sebI 37x6jPM6drWaiNdjjih99Rw4H8GYrvyywmgCBWF9Pk4l4K4wl1xFZuxp3T80e4gp8av8bcoFX3fbG KPx1sKQxz4d9vjLBOrHw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mNAW7-000JZM-G2; Mon, 06 Sep 2021 09:02:15 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mNAW3-000JYo-Oi for linux-arm-kernel@lists.infradead.org; Mon, 06 Sep 2021 09:02:13 +0000 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 24AF660F3A; Mon, 6 Sep 2021 09:02:11 +0000 (UTC) Received: from 82-132-228-124.dab.02.net ([82.132.228.124] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mNAW1-009Dbo-1g; Mon, 06 Sep 2021 10:02:09 +0100 Date: Mon, 06 Sep 2021 10:02:09 +0100 Message-ID: <87k0jucc1a.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, Paolo Bonzini , Sean Christopherson , Peter Shier , Jim Mattson , David Matlack , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Andrew Jones , Will Deacon , Catalin Marinas Subject: Re: [PATCH v7 3/7] KVM: arm64: Allow userspace to configure a vCPU's virtual offset In-Reply-To: References: <20210816001217.3063400-1-oupton@google.com> <20210816001217.3063400-4-oupton@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 82.132.228.124 X-SA-Exim-Rcpt-To: oupton@google.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, seanjc@google.com, pshier@google.com, jmattson@google.com, dmatlack@google.com, ricarkol@google.com, jingzhangos@google.com, rananta@google.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, drjones@redhat.com, will@kernel.org, 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210906_020211_880757_E6FB8372 X-CRM114-Status: GOOD ( 32.30 ) 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 Sun, 29 Aug 2021 03:35:30 +0100, Oliver Upton wrote: > > On Mon, Aug 16, 2021 at 12:12:13AM +0000, Oliver Upton wrote: > > Allow userspace to access the guest's virtual counter-timer offset > > through the ONE_REG interface. The value read or written is defined to > > be an offset from the guest's physical counter-timer. Add some > > documentation to clarify how a VMM should use this and the existing > > CNTVCT_EL0. > > > > Signed-off-by: Oliver Upton > > Reviewed-by: Andrew Jones > > Hrm... > > I was mulling on this patch a bit more and had a thought. As previously > discussed, the patch implements virtual offsets by broadcasting the same > offset to all vCPUs in a guest. I wonder if this may tolerate bad > practices from userspace that will break when KVM supports NV. > > Consider that a nested guest may set CNTVOFF_EL2 to whatever value it > wants. Presumably, we will need to patch the handling of CNTVOFF_EL2 to > *not* broadcast to all vCPUs to save/restore NV properly. If a maligned > VMM only wrote to a single vCPU, banking on this broadcasting > implementation, it will fall flat on its face when handling an NV guest. > > So, should we preemptively move to the new way of the world, wherein > userspace accesses to CNTVOFF_EL2 are vCPU-local rather than VM-wide? > > No strong opinions in either direction, but figured I'd address it since > I'll need to respin this series anyway to fix ECV+nVHE. Thought about this a bit more whilst being away from a computer... It all boils down to what we expose as an abstraction of a machine. If there is no EL2 in the VM, then there shouldn't be any way for the guest to observe different values for the counters as seen from different vcpus. That's what the architecture guarantees for a physical system, and we shouldn't deviate from that. Opening the door for userspace to do anything differently is a recipe for disaster. It actually is an argument in favour of setting the various offsets to a value that keep the two physical and virtual counters in sync, instead of the current behaviour that allows different values to be observed. The above is in contrast with what the architecture allows when EL2 is present. The hypervisor can naturally deal with the offsets as it sees fit, and no offset should have any bearing on it (this later point is of course to be moderated by CNTPOFF on the host). To sum it up, I'd rather keep the CNTVOFF behaviour what it is today for guest that have their highest exception level at EL1. For EL2 guests, the setting will obviously have to become per-CPU. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel