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.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 05D42C432BE for ; Sun, 29 Aug 2021 02:38:18 +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 B57A460E90 for ; Sun, 29 Aug 2021 02:38:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B57A460E90 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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: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=3hS4SPzZTHUJS8W+6laHGpfCJjFY6BVqxuGpU72Mv/E=; b=2RGvXZs41E2rpu 5YCmkd9ltm4X9dKSlFooTD/zxLFrVr0Fsw8zzcTMawXc4M8WqhgCgK3zK9a5y4pKqZCdFyp4EkAEo Eq+SKHUGzWlX71KAvywQqlw1pGj5FIxvbJp54+WN6x7q2N2KlsWpjcbVZ/Hrvo6EzoMM4EWQAqyNy HcViYn5HUg5a97neFsvAu5Kgl3JaauSOUcQMXhKWBMKRbNcd3pzhR6Ig0mVx6vv5tTtfaWYAu2N0M LnnYqww/yWQjJFxZZhoC98NN3Pr6ROqXetEMsqq6aGXkSGEhqVc02/MjldQ4Xb+UjXrSxk43WeBDs hF38S22f8AAvWYx/mAOQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKAfi-00Euy8-Fv; Sun, 29 Aug 2021 02:35:46 +0000 Received: from mail-il1-x135.google.com ([2607:f8b0:4864:20::135]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKAfd-00Euxh-RT for linux-arm-kernel@lists.infradead.org; Sun, 29 Aug 2021 02:35:43 +0000 Received: by mail-il1-x135.google.com with SMTP id g8so11787991ilc.5 for ; Sat, 28 Aug 2021 19:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RudsPPL2jXFkdPRzt+igCskpzL+QGPjfc2x3ccwPC9w=; b=J9dShv8oT22vhmmqH2pkP0XLxIOEJ7tW9eSIEdnG1fyr3GwcpVNpmGYZWHtUTPwbdc lKZST7xRrEZtCCb+YWt8Xhzpj6P/kSiXR0smrgRiSTf5HtapPENUniwt6x6XneYgBx0f MhIbbwvej2DS9j87DesFkvJyYr27DVk+uIr34OeQabcGSnyM56UwM+VJQyZowkGY0Neh OsWFl9GKalS1FqlEsxb3bHlOl0fYVMlSmFGYXE7WCyXLDSvB9bwTTYN1vCxZ84vvyh5r lSjypE12DhI1TxK1lGSxbhqQx8NkclxW++kh+LZbm+cV6BzzD9CA8RVPG7HK+8BEXDGe 18qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RudsPPL2jXFkdPRzt+igCskpzL+QGPjfc2x3ccwPC9w=; b=oQNO8kth6Y5K7qT2TQYC48sP3ZCspoqS2w3n7gbaEMCpOwVGlB1Xh+G23g5QIF0klr 1Qva6OL10zEZN1t1L2HKBvKC74CccYVqfJj4+D0hBuTIBH55BoMlPwN+jkH7UPscB5T3 d1f69nWfQaCAZ1AM5QIt2T6FPVZwxFwWcqZ5v/7jmywlXY82vBqvBnBmiX3We0QKrYmL tUOIAXb8+rUzjjI7pWD6UB0lR5ZOWE0cdi3o9UyvdHDEKp1dhTb1y/UPMQFfM3mOzGPd pZlGe4ypf/qRw9NP03laIkKqhrP0xCgbTZyz5iFTLto8lcUJvkYPT4m/qim6sNstfQAt pMjg== X-Gm-Message-State: AOAM532jsMn+ax34ygB5RoRWhPaujPgB2ey6QA4gMVj4Cm6DLakQqxgX lAXLVQwyGbznt0E8ZrMWqWQXfw== X-Google-Smtp-Source: ABdhPJwqUHMTxEkDQA8hFpGHHEo0tu8/O2NMjK/5E7lfYuh/Mo0XzToNBlb9dDEkFv0S5CWvSmaOLA== X-Received: by 2002:a92:cda4:: with SMTP id g4mr11981754ild.236.1630204534995; Sat, 28 Aug 2021 19:35:34 -0700 (PDT) Received: from google.com (194.225.68.34.bc.googleusercontent.com. [34.68.225.194]) by smtp.gmail.com with ESMTPSA id h11sm1851451ilc.7.2021.08.28.19.35.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Aug 2021 19:35:34 -0700 (PDT) Date: Sun, 29 Aug 2021 02:35:30 +0000 From: Oliver Upton To: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu Cc: Paolo Bonzini , Sean Christopherson , Marc Zyngier , 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 Message-ID: References: <20210816001217.3063400-1-oupton@google.com> <20210816001217.3063400-4-oupton@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210816001217.3063400-4-oupton@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210828_193541_938985_9A9BE492 X-CRM114-Status: GOOD ( 16.51 ) 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 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. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel