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 DC70DC4332F for ; Tue, 22 Nov 2022 09:55:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F86D8E0001; Tue, 22 Nov 2022 04:55:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A82B6B0073; Tue, 22 Nov 2022 04:55:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 548E38E0001; Tue, 22 Nov 2022 04:55:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 46A0B6B0071 for ; Tue, 22 Nov 2022 04:55:00 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1E10440A7E for ; Tue, 22 Nov 2022 09:55:00 +0000 (UTC) X-FDA: 80160619560.09.704625A Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf18.hostedemail.com (Postfix) with ESMTP id 679BF1C000A for ; Tue, 22 Nov 2022 09:54:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669110898; x=1700646898; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=rJIOCd9N5PvCN1hTjd1er2T0b67rVXxGjK1ymZuckrA=; b=BEqFrXNjy/3fKu4wNFa0KsGXYTeAjS0h+loKaJ8/r48pNftxlAjg2y4P ICzFrY9I7D/UJKzLJ9g1Vwt/CG/E+ON1cgGoP8SQVdjvabvWqm6XgC8EV yAWSNNggatKWlIbrdd0kZPV97rlw+80I8efyt+qBj/Fu/5FEeg2c0CE+O nb8XNQwrdoUTX7F+6yAvcbW3OZuD814lAiMgeiT/ystMfAWc8WCYeWmNZ BY98lga53BUkv3TQj9JZUQxvK7BqQFwIRkOo27B5X+cPibrCXqFfzMyZT Hjf/O+xnjypQQ0uK3QQF+TM1UPMKq2LpIx3A2oKpcP/Plpx3ZjsVu3jSm w==; X-IronPort-AV: E=McAfee;i="6500,9779,10538"; a="311407485" X-IronPort-AV: E=Sophos;i="5.96,183,1665471600"; d="scan'208";a="311407485" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2022 01:54:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10538"; a="635489296" X-IronPort-AV: E=Sophos;i="5.96,183,1665471600"; d="scan'208";a="635489296" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.193.75]) by orsmga007.jf.intel.com with ESMTP; 22 Nov 2022 01:54:45 -0800 Date: Tue, 22 Nov 2022 17:50:22 +0800 From: Chao Peng To: Sean Christopherson 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: <20221122095022.GA617784@chaop.bj.intel.com> Reply-To: Chao Peng References: <20221025151344.3784230-1-chao.p.peng@linux.intel.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=BEqFrXNj; spf=none (imf18.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669110898; a=rsa-sha256; cv=none; b=3/u+6595qLijPFodOo9mAYKEeAChRQfNki5Sd/Lqau2pmtaVLHyTGl/OKUPXtj3kkqwISZ zF7Ukj9XctbGJVQ9Ou80IzX+cODg1B7VzWl+fh/8tzBDI7P1FWuyW47wC+uixkMw1GHenI 53xM0Z5COffS6dA2FjAf7NYp8UgcrAo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669110898; h=from:from:sender:reply-to: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=L0GMdsi8O8B8+vfCil4JC14yfNsudD1HsYMi4sUJZ+I=; b=pdQu2h58QjKGMct5ZjmSz1vMzp9fWaiVarYJv+WVUY/N/rRgj1OYhRHsP0S7kGpYxfESp1 MGR1if0F/4+0q8npUxLxReesA3x0X1uRsfOjDgNiYM9PDkYAeT9YIJN3xsP5DxYRBggf29 6Ea7U5xObvYOVm408jNqwmftHZswcUs= X-Rspamd-Queue-Id: 679BF1C000A X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=BEqFrXNj; spf=none (imf18.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspamd-Server: rspam06 X-Stat-Signature: nkrxcpjiwudhey8dyjnk7usxiokngxye X-HE-Tag: 1669110898-757482 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 Fri, Nov 18, 2022 at 03:59:12PM +0000, Sean Christopherson wrote: > On Fri, Nov 18, 2022, Alex Benn?e wrote: > > > > Chao Peng writes: > > > > > On Thu, Nov 17, 2022 at 03:08:17PM +0000, Alex Benn?e wrote: > > >> >> I think this should be explicit rather than implied by the absence of > > >> >> another flag. Sean suggested you might want flags for RWX failures so > > >> >> maybe something like: > > >> >> > > >> >> KVM_MEMORY_EXIT_SHARED_FLAG_READ (1 << 0) > > >> >> KVM_MEMORY_EXIT_SHARED_FLAG_WRITE (1 << 1) > > >> >> KVM_MEMORY_EXIT_SHARED_FLAG_EXECUTE (1 << 2) > > >> >> KVM_MEMORY_EXIT_FLAG_PRIVATE (1 << 3) > > >> > > > >> > Yes, but I would not add 'SHARED' to RWX, they are not share memory > > >> > specific, private memory can also set them once introduced. > > >> > > >> OK so how about: > > >> > > >> KVM_MEMORY_EXIT_FLAG_READ (1 << 0) > > >> KVM_MEMORY_EXIT_FLAG_WRITE (1 << 1) > > >> KVM_MEMORY_EXIT_FLAG_EXECUTE (1 << 2) > > >> KVM_MEMORY_EXIT_FLAG_SHARED (1 << 3) > > >> KVM_MEMORY_EXIT_FLAG_PRIVATE (1 << 4) > > > > > > 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". > > 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) > > The RWX bits are in the same boat, e.g. the READ flag isn't strictly necessary. > I was thinking more of the KVM_SET_MEMORY_ATTRIBUTES ioctl(), which does need > the full RWX gamut, when I typed out that response. For KVM_SET_MEMORY_ATTRIBUTES it's reasonable to add RWX bits and match that to the permission bits definition in EPT entry. > > 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. Chao