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=-8.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 D2DEFC432BE for ; Sun, 29 Aug 2021 02:35:44 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 52ABF60E99 for ; Sun, 29 Aug 2021 02:35:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 52ABF60E99 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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 C2A314B0BB; Sat, 28 Aug 2021 22:35:43 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com 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 5GA7pgfcXwQE; Sat, 28 Aug 2021 22:35:39 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D8F594B132; Sat, 28 Aug 2021 22:35:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9A7E54B12D for ; Sat, 28 Aug 2021 22:35:38 -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 cvYGV9psMzNQ for ; Sat, 28 Aug 2021 22:35:36 -0400 (EDT) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id EE81A4B0BB for ; Sat, 28 Aug 2021 22:35:35 -0400 (EDT) Received: by mail-il1-f176.google.com with SMTP id l10so11777607ilh.8 for ; Sat, 28 Aug 2021 19:35:35 -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=FD1IDjz+dFZ3sHevff3HfHrImhV/dqYbVwr/0QVzqPzU4QFKmAbMdCrfuSK/4b1XEL j3HOYaOs7W9A4Fr9cAte7uZ0ixbDJghzFp11FVsSYleBQAupQNNlwpK8ZKOl0a3CHqan mKVYTILPYjD+yBEXgj4BQrXoOXTb0KbrKCLYlnhannFj/JkEdS3YEK0cArp1xjNpqRkC TS4qEwdBqmxAH6A6PJBn6b10IDHlqYCShmIlwNob6H/1/ewD+/M8vPofduS8it+SYXwY UsmF4iC8HnOr5fnbgehhIhul9Ofiri5dIeKhMsGVJLB2R+X+oK2GlW8hlv2M31/QygN1 UfMA== X-Gm-Message-State: AOAM532Fdf21Y90MIMxa2o/2K7dqz8CradmjAcPWRzYAZdAGxyNz+LBS FKRygGd2oBmL76+tn+22T+rz/w== 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 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> Cc: Catalin Marinas , Will Deacon , Marc Zyngier , Peter Shier , Sean Christopherson , David Matlack , Paolo Bonzini , 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 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 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL 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 4826AC432BE for ; Sun, 29 Aug 2021 02:35:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1B51C60E90 for ; Sun, 29 Aug 2021 02:35:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233635AbhH2Cg2 (ORCPT ); Sat, 28 Aug 2021 22:36:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230334AbhH2Cg1 (ORCPT ); Sat, 28 Aug 2021 22:36:27 -0400 Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 313C4C061756 for ; Sat, 28 Aug 2021 19:35:36 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id s16so11781726ilo.9 for ; Sat, 28 Aug 2021 19:35:36 -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=Z2fgwVSEubtoi3ZwLNwKjmT7/ikjSFge4VLPUZPVkIrm9dgikWt4Tw1ps8kSfRv4Py 026gUYg2dHZwzjathRA/AACWf6cC+R03xhESkzZ3ffzhuol8X+dfiS9hx9vY6rcytiDW YTUFp9rVa9OxyaycnSQXo0c3LEh8a93iKfevGgSlbFZGefeS2rWaCP69gS1jfmQE5Bsf ardviGdr1kMXY/XEUEPZ3XhBH/QVZexsybTapTrZDsJRgHRHqDSitLCIM2HYdt4UY2S0 hSUkuZwfV0RglWIUySpB1+j1KD43oU1zZx6qt7TtVKMT2NlddSTNS5Mjm4DCr0Lz8y8G QqoA== X-Gm-Message-State: AOAM533nzPGebWHaeDkehilpeeDiJLTRp5y35wOvKtKFU29WGH3eo7od /BqPmWadvseTdbvSu52KhL6PVI5JYbNgssIB 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210816001217.3063400-4-oupton@google.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.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