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 CBEBFEB64DD for ; Thu, 20 Jul 2023 19:02:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CCFB280151; Thu, 20 Jul 2023 15:02:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17D8F28004C; Thu, 20 Jul 2023 15:02:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01D9A280151; Thu, 20 Jul 2023 15:02:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E66DA28004C for ; Thu, 20 Jul 2023 15:02:17 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A241A40259 for ; Thu, 20 Jul 2023 19:02:17 +0000 (UTC) X-FDA: 81032910714.18.241FCF7 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf17.hostedemail.com (Postfix) with ESMTP id 5122A40012 for ; Thu, 20 Jul 2023 19:02:15 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=HmFZ4aH4; spf=pass (imf17.hostedemail.com: domain of isaku.yamahata@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=isaku.yamahata@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689879735; a=rsa-sha256; cv=none; b=v02EtexRCHwm7WxO7YJX7G07SiZhFny90hEgJN3VidFsbq4fjS1wgfNff0O3mFYw0mZQUy r4CU2ajBh1y0BzGZSLxepyJnxsMztMSNaH0TV0RjT2KpAIH2mKnjdiomwcgE06qY0ZG7Tr BHCSNAxPHwGrnueJ5EWwLGvNemIUQK4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=HmFZ4aH4; spf=pass (imf17.hostedemail.com: domain of isaku.yamahata@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=isaku.yamahata@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689879735; 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=0MSKcIw1ixdNRcp/f0sV+4F1n8XKG7sdC3dJK2xndKs=; b=MYLtBUf26E3zOJHjETAoZFTiKMqvINwmL6phDj2mxhGvTSZODumRZFbib2PQC6lCc2ETIx GtRU4ZVW9vLfhOSo95/ngDOP8GtfVUftwtZ/9PikU66VZvuCfF9fo0mZtWUte6Z5qtUYLg cLRVenL1y+aRmjwQArgVwu1VbLnI+os= Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1bb1baf55f5so8596175ad.0 for ; Thu, 20 Jul 2023 12:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689879734; x=1690484534; 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=0MSKcIw1ixdNRcp/f0sV+4F1n8XKG7sdC3dJK2xndKs=; b=HmFZ4aH4Wab+GqCN9TB1hsoxANs59ZGyg6e/EgDXSJq0eYSI/1VDWVlSgNIChLUfV8 T/IU56bnENLrhgdM87GnmjNFM0RpmjvZJl2xcorFy1mGsUnDs9zdzDKZrSPzHq2hoIH0 vFw+TuHLIpDpLy2T1GRQp+A/ZwejC2JNC9/kx8GgLOzFDvivXFRt8pK7pg/RJqO6epII jU9EDNCAY3cGtv9Kz4M3mnp24C7KZYOlNZNUgyGjPKzywths6r+RNrsvvKuGeUeTpvFE KzSBguxslln865ERYszYEUEyvYxe2xDbUJMXe4XuzyfRHn+tbMW1SUTP9WASXJn7b+Pn qf5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689879734; x=1690484534; 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=0MSKcIw1ixdNRcp/f0sV+4F1n8XKG7sdC3dJK2xndKs=; b=DBcHRH67g+09UsTOpvnO/2Eb/7zJKQAfWLbzAom8563/V7Z2Hi+/kQ45E4aYjF1DvV YTjUCiDb8xmtqJLn4J6D8vi8aA+uA34fKsNdVUl4YWAeT2gYDqIMIk83lJ3z6BtAqEp6 AvXhwlmpSKfIeURrYPTBXvrTIzG5bSUx0WWgN8+FL5q/vdz7+QnZMy6EwyDuUoJOjJnU aYpWgVcogdsZQkYxzowrVQIx6jL4vIpPqOBiIWrBwKNt19SboBJVK4B+hg9IrI5AsAWV nJeKGHVBk4gvvackDSMmq5mr46t4gpVVkuXcNbVamZGTeQf5rE0EZjm9ItwHivfuCtL+ b2sA== X-Gm-Message-State: ABy/qLYR1GqIBpMpiigHmg+u+RfbIxkggylXu9Bna4GE4V8nMom8Ho7m gaD/yqlkYYLMPmNIr2Xq82c= X-Google-Smtp-Source: APBJJlEk/mIAgGdv75eqlacWKafqLMEC8fcDRiP+uJ4q0KoW6Z/oWLHWzhtG4Xil0kxFMatYBl1SNg== X-Received: by 2002:a17:902:cec9:b0:1ba:fe63:6622 with SMTP id d9-20020a170902cec900b001bafe636622mr138625plg.32.1689879733690; Thu, 20 Jul 2023 12:02:13 -0700 (PDT) Received: from localhost ([192.55.54.50]) by smtp.gmail.com with ESMTPSA id d15-20020a170903230f00b001b9de4fb749sm1778146plh.20.2023.07.20.12.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 12:02:12 -0700 (PDT) Date: Thu, 20 Jul 2023 12:02:11 -0700 From: Isaku Yamahata To: Yuan Yao Cc: Sean Christopherson , Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Yu Zhang , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , Vlastimil Babka , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Subject: Re: [RFC PATCH v11 08/29] KVM: Introduce per-page memory attributes Message-ID: <20230720190211.GF25699@ls.amr.corp.intel.com> References: <20230718234512.1690985-1-seanjc@google.com> <20230718234512.1690985-9-seanjc@google.com> <20230720080912.g56zi5hywazrhnam@yy-desk-7060> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230720080912.g56zi5hywazrhnam@yy-desk-7060> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5122A40012 X-Stat-Signature: 9mz1iuub7i3tm3efsg93oaqio1ixwzjw X-Rspam-User: X-HE-Tag: 1689879735-331018 X-HE-Meta: U2FsdGVkX1/ycm/x5njL/TULtGVXguGrlf1WDILYedZSZW/XSlw8iYoYOA5kUFgdReITvyJ8JfHOkENn3KnId9XTeg3RVfBi8boLjM6mmjLioQEuhQXk+HpEJGZws0EVVcPO2Mc4fX1868G+v9sH1v77jM8/Cv4JTNP6V44RNQJD0DNySID+KeasjS3a1PTeKz1lXPpEzv1vlOPS5+Av2MvZFeIgQp9d0pVNN8JtdMkLFlGZ2S0hoP/EfpfH9mzf1B0h8YhMC4vqgFUxiNSgEoFWfmr/ucXw4hh1F208g31Afi+uH5yArluAtU8fjnzpsTRvNaX2iovj9NCx5r7YFIEA/WLyjrutvBf9p/K9OiQK7Y3epTjXcSCE+dyLL2STr7mhQPDVkb1LXcQg9wg9BYadgPCniR21v44jgDc2LVsqADZO02gr6fewF9DEmyz14aYBGZxJXhmRz2nf/rPZUEM2JfNtg3b0ZxpaFPaneDQemvVwMY9LTFffrZ+TXFMIFDZCmHmkt6KPjIZEJlkzVR9CmqZrW9u0/n/o6rACCmC9pLH9PsUkurus+QfKSkneg3ZrT2CPKmn3M+0h6inxGNiQchmJTQZ/XNclvddLOK3TkIm4pBAvkbkuQVnDySymqoBPWHYRC+ItaIpL8hqhTqTVifqeEAfjHi97l10T296JYCcIYDRaAcIOu8xlZqPvmcyoC0ToGaxIQJ+IXk0gUj26ezj0Eae+p7vbUs8I+DH36JQDNtqjE4Fw3LftE1pLGYE6T3Y9NzvG2fZHeIxSeH+za1aE/MuE5LHpCBtTr2vLUL16IfynbizCDPZwegwJPejCiNEPXZSoCbV2K2ic/RGm2e2gIfiVNZS1R7P3IxQVUiJX3WH4OO0zN4tAuNwY7VlyNW53yKMjT0pGqSyJHJYEG6sFzVwFrye3dxM0t9QaTJVUWjpOYHEiBdxx1EocaKrQo9bruZf9VYr7WrX D4FYZdJN Dub7yr6nCrsx5sCX6D9tQOTScb+S0gtgXhlOoZeIxX0l9+yEPb953TAIWpxfeo953CmlpcWm/LPACk7PtrcW07hjRrUGHNELhOxwRaAnfNZynro2ZJB4Qg2WhSvTc0lYJZThLNTfmxdQY7FjodMpTWXixGDtGJICVjakMzpfraT0D8TbGr5v/GieeReYDxUS5XbrKNkqxwK/fioqvPN95wRNPt89hqS64UVj8gETcN0jGnr/N3YDVNV94756Env/oUf7vceyzbuSXLrS5cMci99pQwDDm2nt8vfaSiPpD9H23CdyozhKouD0pUB9Q1508SYEb3OtsjMCRVeNAr5h8s1HqYkvEo881Q6F/OSXCEwbKAflhsek+oCEAFCnbSgakMt3BdvQLJFQjBMTz2hWcRfiJhpH20xUGJ63lGXwiMCAL/tvgTIJBakaw8hQm09PEhZBLo1xyWMLaB7KEzximCfD+aGbS498lhLylgQ5VDQylSDPp7lHPFIcOin22+Q0oaPREPR/qy/QmpK9pRtKMekBHMLbyLepkFQ5fW+MHfNga/byDUQnea52Kc5nrELQqFxCXI7eW4V/SgMrGsekF51OLN9q/rqACoW85GFdzrQD/y5+jSiLavfbD2w== 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 Thu, Jul 20, 2023 at 04:09:12PM +0800, Yuan Yao wrote: > On Tue, Jul 18, 2023 at 04:44:51PM -0700, Sean Christopherson wrote: > > From: Chao Peng > > > > In confidential computing usages, whether a page is private or shared is > > necessary information for KVM to perform operations like page fault > > handling, page zapping etc. There are other potential use cases for > > per-page memory attributes, e.g. to make memory read-only (or no-exec, > > or exec-only, etc.) without having to modify memslots. > > > > Introduce two ioctls (advertised by KVM_CAP_MEMORY_ATTRIBUTES) to allow > > userspace to operate on the per-page memory attributes. > > - KVM_SET_MEMORY_ATTRIBUTES to set the per-page memory attributes to > > a guest memory range. > > - KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES to return the KVM supported > > memory attributes. > > > > Use an xarray to store the per-page attributes internally, with a naive, > > not fully optimized implementation, i.e. prioritize correctness over > > performance for the initial implementation. > > > > Because setting memory attributes is roughly analogous to mprotect() on > > memory that is mapped into the guest, zap existing mappings prior to > > updating the memory attributes. Opportunistically provide an arch hook > > for the post-set path (needed to complete invalidation anyways) in > > anticipation of x86 needing the hook to update metadata related to > > determining whether or not a given gfn can be backed with various sizes > > of hugepages. > > > > It's possible that future usages may not require an invalidation, e.g. > > if KVM ends up supporting RWX protections and userspace grants _more_ > > protections, but again opt for simplicity and punt optimizations to > > if/when they are needed. > > > > Suggested-by: Sean Christopherson > > Link: https://lore.kernel.org/all/Y2WB48kD0J4VGynX@google.com > > Cc: Fuad Tabba > > Signed-off-by: Chao Peng > > Co-developed-by: Sean Christopherson > > Signed-off-by: Sean Christopherson > > --- > > Documentation/virt/kvm/api.rst | 60 ++++++++++++ > > include/linux/kvm_host.h | 14 +++ > > include/uapi/linux/kvm.h | 14 +++ > > virt/kvm/Kconfig | 4 + > > virt/kvm/kvm_main.c | 170 +++++++++++++++++++++++++++++++++ > > 5 files changed, 262 insertions(+) > > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > > index 34d4ce66e0c8..0ca8561775ac 100644 > > --- a/Documentation/virt/kvm/api.rst > > +++ b/Documentation/virt/kvm/api.rst > > @@ -6068,6 +6068,56 @@ writes to the CNTVCT_EL0 and CNTPCT_EL0 registers using the SET_ONE_REG > > interface. No error will be returned, but the resulting offset will not be > > applied. > > > > +4.139 KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES > > +----------------------------------------- > > + > > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES > > +:Architectures: x86 > > +:Type: vm ioctl > > +:Parameters: u64 memory attributes bitmask(out) > > +:Returns: 0 on success, <0 on error > > + > > +Returns supported memory attributes bitmask. Supported memory attributes will > > +have the corresponding bits set in u64 memory attributes bitmask. > > + > > +The following memory attributes are defined:: > > + > > + #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3) > > + > > +4.140 KVM_SET_MEMORY_ATTRIBUTES > > +----------------------------------------- > > + > > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES > > +:Architectures: x86 > > +:Type: vm ioctl > > +:Parameters: struct kvm_memory_attributes(in/out) > > +:Returns: 0 on success, <0 on error > > + > > +Sets memory attributes for pages in a guest memory range. Parameters are > > +specified via the following structure:: > > + > > + struct kvm_memory_attributes { > > + __u64 address; > > + __u64 size; > > + __u64 attributes; > > + __u64 flags; > > + }; > > + > > +The user sets the per-page memory attributes to a guest memory range indicated > > +by address/size, and in return KVM adjusts address and size to reflect the > > +actual pages of the memory range have been successfully set to the attributes. > > +If the call returns 0, "address" is updated to the last successful address + 1 > > +and "size" is updated to the remaining address size that has not been set > > +successfully. The user should check the return value as well as the size to > > +decide if the operation succeeded for the whole range or not. The user may want > > +to retry the operation with the returned address/size if the previous range was > > +partially successful. > > + > > +Both address and size should be page aligned and the supported attributes can be > > +retrieved with KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES. > > + > > +The "flags" field may be used for future extensions and should be set to 0s. > > + > > 5. The kvm_run structure > > ======================== > > > > @@ -8494,6 +8544,16 @@ block sizes is exposed in KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES as a > > 64-bit bitmap (each bit describing a block size). The default value is > > 0, to disable the eager page splitting. > > > > +8.41 KVM_CAP_MEMORY_ATTRIBUTES > > +------------------------------ > > + > > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES > > +:Architectures: x86 > > +:Type: vm > > + > > +This capability indicates KVM supports per-page memory attributes and ioctls > > +KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES/KVM_SET_MEMORY_ATTRIBUTES are available. > > + > > 9. Known KVM API problems > > ========================= > > > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index e9ca49d451f3..97db63da6227 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@ -264,6 +264,7 @@ struct kvm_gfn_range { > > gfn_t end; > > union { > > pte_t pte; > > + unsigned long attributes; > > u64 raw; > > } arg; > > bool may_block; > > @@ -809,6 +810,9 @@ struct kvm { > > > > #ifdef CONFIG_HAVE_KVM_PM_NOTIFIER > > struct notifier_block pm_notifier; > > +#endif > > +#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > + struct xarray mem_attr_array; > > #endif > > char stats_id[KVM_STATS_NAME_SIZE]; > > }; > > @@ -2301,4 +2305,14 @@ static inline void kvm_account_pgtable_pages(void *virt, int nr) > > /* Max number of entries allowed for each kvm dirty ring */ > > #define KVM_DIRTY_RING_MAX_ENTRIES 65536 > > > > +#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > +static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn) > > +{ > > + return xa_to_value(xa_load(&kvm->mem_attr_array, gfn)); > > +} > > + > > +bool kvm_arch_post_set_memory_attributes(struct kvm *kvm, > > + struct kvm_gfn_range *range); > > Used but no definition in this patch, it's defined in next patch 09. > How about add weak version in this patch and let ARCHs to overide it ? It is guarded by CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES. -- Isaku Yamahata