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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08A44C4332F for ; Wed, 23 Nov 2022 18:02:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 860F36B0071; Wed, 23 Nov 2022 13:02:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 80E556B0073; Wed, 23 Nov 2022 13:02:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D70A6B0074; Wed, 23 Nov 2022 13:02:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 610B16B0071 for ; Wed, 23 Nov 2022 13:02:21 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 334501A08CB for ; Wed, 23 Nov 2022 18:02:21 +0000 (UTC) X-FDA: 80165476482.05.32B1C26 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf25.hostedemail.com (Postfix) with ESMTP id 1EAFBA001F for ; Wed, 23 Nov 2022 18:02:16 +0000 (UTC) Received: by mail-pl1-f182.google.com with SMTP id io19so17330130plb.8 for ; Wed, 23 Nov 2022 10:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=JBAHsDOjy5OO4Ngubx5UMoEA0/sDtPMwp6OMmJM5Kq8=; b=j0pjNho9RlZm19Tehr3FVjo7Db8885B4Y7xkdDdUAoWctaEVu0QXpeH4dAhlT+H/66 rXShciLYPKXX/As5ej1NnFhKVYsgqZOAIM86zq/8g4IoL0rpFkAis4hyMIxH32ObpzTD q12ac2q20Bq/175aKSlrDsis/kh1ZErXHlsfXaFF0vLM0VKl7Q/KOGrAwfHxRNQmXI/O driosPsB+7yejIXs59Nh7GScXFt/2qGI69bVfBSTlUwjFNjy1R5omvxslKZApaKKy6Vb bCz1WtnxHp4F2zgsQTYD/KhQpB2n22TuYLklkc67sIj+R3YF0oMYZg8xQcjMBvZBgqVR chmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JBAHsDOjy5OO4Ngubx5UMoEA0/sDtPMwp6OMmJM5Kq8=; b=CIjWNziQro/Y47JD0/p2kZ+RCmY1ak5dyYCJp5ulhSQR1tw4op14MuiSwULfACRWPk EQO7Cact2EI4rxRKUol2fvNkYohUYz3SYNmCW4I7kQ5KjS9HY52sBWpGH7bGE2YibtcQ SbJnty6UW4HhNdP9rWLpPcARuZqQ588MINEV67rL1K1XQz26m0OyQiegR/L7noYSOM/n S3vjbbYkry7n9+Gfc5tc7Wr28uqlyn6vZxQEdYgA7VLSFQOx0IKBu1RPVea6sqZThvJY oSb5Gzgm8V8hzu5GGx6d9PllvyjkkRJoUQ36+PjYfbxDo2/oGsTllKzvQm4o2wFy8h7a 7A+Q== X-Gm-Message-State: ANoB5pk8ciRrUVvLhh6ZHX9dWNODGPeEGP/LpIs/kRKTBSdOpYP7/rZW blG3cyOFOfhEjZwnYFZHfGgc3Q== X-Google-Smtp-Source: AA0mqf4h/eDzvGfQmUc/ZjBSomm7vgT2Crg1NblOZpQoP8uNf60lMXpAkbUo70CvheBSDG5J9lpZAg== X-Received: by 2002:a17:902:da89:b0:189:8b2:b069 with SMTP id j9-20020a170902da8900b0018908b2b069mr10756414plx.13.1669226535720; Wed, 23 Nov 2022 10:02:15 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id w26-20020a63475a000000b00462612c2699sm11075143pgk.86.2022.11.23.10.02.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Nov 2022 10:02:15 -0800 (PST) Date: Wed, 23 Nov 2022 18:02:11 +0000 From: Sean Christopherson To: Chao Peng Cc: Alex =?utf-8?B?QmVubu+/vWU=?= , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com Subject: Re: [PATCH v9 3/8] KVM: Add KVM_EXIT_MEMORY_FAULT exit Message-ID: References: <20221025151344.3784230-4-chao.p.peng@linux.intel.com> <87cz9o9mr8.fsf@linaro.org> <20221116031441.GA364614@chaop.bj.intel.com> <87mt8q90rw.fsf@linaro.org> <20221117134520.GD422408@chaop.bj.intel.com> <87a64p8vof.fsf@linaro.org> <20221118013201.GA456562@chaop.bj.intel.com> <87o7t475o7.fsf@linaro.org> <20221122095022.GA617784@chaop.bj.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221122095022.GA617784@chaop.bj.intel.com> ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=j0pjNho9; spf=pass (imf25.hostedemail.com: domain of seanjc@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669226537; a=rsa-sha256; cv=none; b=s8xNdfBfg+6zK6x5cH1+ZKkStQpwVgSCUBb73tL0aIrzMiKTeJQTjvQOlW0Crz/uTfIR0i W0TWLvR+s9itmsQlmfb/Y0Dcj0ps+0xWfGye2EkupYYOdr6VpP3hnDxg7xxQ5nIj87DkxN FZUzCpi7mSt2jZ4AJ4gzEg0kXv3EjhU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669226537; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JBAHsDOjy5OO4Ngubx5UMoEA0/sDtPMwp6OMmJM5Kq8=; b=hahaaNqBSBquIOw+0RjINNW6rct66/JCRjJyPQoXcNxWpLFDZ+pPnqGV1DABr3lO5Ef7t1 dXtN0qap50YgcDrtg1FUSDViFxEvbi45aBFDouFlcVBJjQGq++scyjHxQPnFB2yHDHqlm1 Z94wirtKtRjp6GGv/LAhyBnWJmkITek= X-Rspamd-Queue-Id: 1EAFBA001F X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=j0pjNho9; spf=pass (imf25.hostedemail.com: domain of seanjc@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam06 X-Stat-Signature: 48u5i5u7ea15cfcs5jqdenez4gcg73f5 X-HE-Tag: 1669226536-914522 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 22, 2022, Chao Peng wrote: > On Fri, Nov 18, 2022 at 03:59:12PM +0000, Sean Christopherson wrote: > > On Fri, Nov 18, 2022, Alex Benn?e wrote: > > > > We don't actually need a new bit, the opposite side of private is > > > > shared, i.e. flags with KVM_MEMORY_EXIT_FLAG_PRIVATE cleared expresses > > > > 'shared'. > > > > > > If that is always true and we never expect a 3rd type of memory that is > > > fine. But given we are leaving room for expansion having an explicit bit > > > allows for that as well as making cases of forgetting to set the flags > > > more obvious. > > > > Hrm, I'm on the fence. > > > > A dedicated flag isn't strictly needed, e.g. even if we end up with 3+ types in > > this category, the baseline could always be "private". > > The baseline for the current code is actually "shared". Ah, right, the baseline needs to be "shared" so that legacy code doesn't end up with impossible states. > > I do like being explicit, and adding a PRIVATE flag costs KVM practically nothing > > to implement and maintain, but evetually we'll up with flags that are paired with > > an implicit state, e.g. see the many #PF error codes in x86. In other words, > > inevitably KVM will need to define the default/base state of the access, at which > > point the base state for SHARED vs. PRIVATE is "undefined". > > Current memory conversion for confidential usage is bi-directional so we > already need both private and shared states and if we use one bit for > both "shared" and "private" then we will have to define the default > state, e.g, currently the default state is "shared" when we define > > KVM_MEMORY_EXIT_FLAG_PRIVATE (1 << 0) ... > > So I would say if we add an explicit READ flag, then we might as well add an explicit > > PRIVATE flag too. But if we omit PRIVATE, then we should omit READ too. > > Since we assume the default state is shared, so we actually only need a > PRIVATE flag, e.g. there is no SHARED flag and will ignore the RWX for now. Yeah, I'm leading towards "shared" being the implied default state. Ditto for "read" if/when we need to communicate write/execute information E.g. for VMs that don't support guest private memory, the "shared" flag is in some ways nonsensical. Worst case scenario, e.g. if we end up with variations of "shared", we'll need something like KVM_MEMORY_EXIT_FLAG_SHARED_RESTRICTIVE or whatever, but the basic "shared" default will still work.