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.0 required=3.0 tests=BAYES_00,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 A7DD5C433F5 for ; Mon, 6 Sep 2021 09:02:17 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 048AF60F3A for ; Mon, 6 Sep 2021 09:02:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 048AF60F3A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 898524B2A0; Mon, 6 Sep 2021 05:02:16 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP8DW6mVzN67; Mon, 6 Sep 2021 05:02:14 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A9D374B2C5; Mon, 6 Sep 2021 05:02:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 26CBD4B2A0 for ; Mon, 6 Sep 2021 05:02:14 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTXsfWMR0krn for ; Mon, 6 Sep 2021 05:02:12 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 27A274B256 for ; Mon, 6 Sep 2021 05:02:12 -0400 (EDT) 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 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 Cc: Catalin Marinas , kvm@vger.kernel.org, Will Deacon , Sean Christopherson , Peter Shier , David Matlack , Paolo Bonzini , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Jim Mattson X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm