From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Wed, 20 Sep 2023 14:00:22 -0700 Subject: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes In-Reply-To: References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-12-seanjc@google.com> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Sep 15, 2023, Yan Zhao wrote: > On Wed, Sep 13, 2023 at 06:55:09PM -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. > > > ... > >> +bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attrs) > > +{ > > + XA_STATE(xas, &kvm->mem_attr_array, start); > > + unsigned long index; > > + bool has_attrs; > > + void *entry; > > + > > + rcu_read_lock(); > > + > > + if (!attrs) { > > + has_attrs = !xas_find(&xas, end); > > + goto out; > > + } > > + > > + has_attrs = true; > > + for (index = start; index < end; index++) { > > + do { > > + entry = xas_next(&xas); > > + } while (xas_retry(&xas, entry)); > > + > > + if (xas.xa_index != index || xa_to_value(entry) != attrs) { > Should "xa_to_value(entry) != attrs" be "!(xa_to_value(entry) & attrs)" ? No, the exact comparsion is deliberate. The intent of the API is to determine if the entire range already has the desired attributes, not if there is overlap between the two. E.g. if/when RWX attributes are supported, the exact comparison is needed to handle a RW => R conversion. > > + has_attrs = false; > > + break; > > + } > > + } > > + > > +out: > > + rcu_read_unlock(); > > + return has_attrs; > > +} > > + > ... > > +/* Set @attributes for the gfn range [@start, @end). */ > > +static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attributes) > > +{ > > + struct kvm_mmu_notifier_range pre_set_range = { > > + .start = start, > > + .end = end, > > + .handler = kvm_arch_pre_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_begin, > > + .flush_on_ret = true, > > + .may_block = true, > > + }; > > + struct kvm_mmu_notifier_range post_set_range = { > > + .start = start, > > + .end = end, > > + .arg.attributes = attributes, > > + .handler = kvm_arch_post_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_end, > > + .may_block = true, > > + }; > > + unsigned long i; > > + void *entry; > > + int r = 0; > > + > > + entry = attributes ? xa_mk_value(attributes) : NULL; > Also here, do we need to get existing attributes of a GFN first ? No? @entry is the new value that will be set for all entries. This line doesn't touch the xarray in any way. Maybe I'm just not understanding your question. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21F8241AB9 for ; Wed, 20 Sep 2023 21:00:24 +0000 (UTC) Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-d81a47e12b5so447889276.0 for ; Wed, 20 Sep 2023 14:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695243624; x=1695848424; darn=lists.linux.dev; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=WD85YU6GCdPtOsLZeVlIeZZfzAYdtoOH/7wu6gyWXNI=; b=k5kWbmlw6d8Ytb3B5+0pdGzjP74fD9imjogHxnilOX3G5flVxJ4zkemxngzGv9kVOR QfZIK51e+ajEh3QHmbSKB6WAidNyDURx517F/KKyC2WV7vu5XxXDNdNydBi29epN58Jg TaQ2S25G+31R+by2aio37FGPi3dMJGE6JP4t1DU/R0rwRjGdBJMJUGNEHegPMrbDXJWe TrQE2xz+1oxcCfIIBmoayiF1SW7ZtH946z1gA5UZSU5GCbVknIx8SQLUdxYI86q4UNLS Q3d2FxkIiaggYGVTh8vlyUHfZ7oIDOX8g5kJK05sTm3/60VwiGOowe206rFgc3hIwr0y hYMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695243624; x=1695848424; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WD85YU6GCdPtOsLZeVlIeZZfzAYdtoOH/7wu6gyWXNI=; b=T2NYmnruCqox9GiQHwozP3NlrYVyyJj3XGpHUfuipSNQez7wKra0znw5YkkxwuvLUb OapvMyRBk97oiOxy2DaF/gyd9feP9TxCE5joUuUep3ADGvh9kqfX74y6WGCOP4lJ3Lux ux4wVAsMQXC0yVO5BFNxmOurOKgI5u5DIaIKKYAVdYSRUWB27KjfmEujjuLJloh6O+4U WO1JP1dLABIwQFolxEnqeMQAtReobirqL8M8Jucu5CLYSrLbKYxKdUJH4/73NiOaZNJf B0UVOx+wJfsZMqAuzbbRfPu3m+nt6FVzu+Fg4I0OWyPUsgevhIjVfT9urFI0IZ09KIQe RwYQ== X-Gm-Message-State: AOJu0Yw+dfxn+ZekPbXWpuKC1sVMYR+8wZUajVoEL3ZmwKBJM1gbec7b H7HVos4rVwDwKKHVkM4Flcn1XvISs8U= X-Google-Smtp-Source: AGHT+IE6bowhyf6hyHthYBPyW6IZfmwFxVZA3ErkF6QZibGvin1ESoG81Vf7MPhR8G5wDRxCxsmQT8EV7w4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:496:0:b0:d7f:2cb6:7d88 with SMTP id 144-20020a250496000000b00d7f2cb67d88mr58003ybe.13.1695243624102; Wed, 20 Sep 2023 14:00:24 -0700 (PDT) Date: Wed, 20 Sep 2023 14:00:22 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-12-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Yan Zhao Cc: 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 , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Content-Type: text/plain; charset="us-ascii" On Fri, Sep 15, 2023, Yan Zhao wrote: > On Wed, Sep 13, 2023 at 06:55:09PM -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. > > > ... > >> +bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attrs) > > +{ > > + XA_STATE(xas, &kvm->mem_attr_array, start); > > + unsigned long index; > > + bool has_attrs; > > + void *entry; > > + > > + rcu_read_lock(); > > + > > + if (!attrs) { > > + has_attrs = !xas_find(&xas, end); > > + goto out; > > + } > > + > > + has_attrs = true; > > + for (index = start; index < end; index++) { > > + do { > > + entry = xas_next(&xas); > > + } while (xas_retry(&xas, entry)); > > + > > + if (xas.xa_index != index || xa_to_value(entry) != attrs) { > Should "xa_to_value(entry) != attrs" be "!(xa_to_value(entry) & attrs)" ? No, the exact comparsion is deliberate. The intent of the API is to determine if the entire range already has the desired attributes, not if there is overlap between the two. E.g. if/when RWX attributes are supported, the exact comparison is needed to handle a RW => R conversion. > > + has_attrs = false; > > + break; > > + } > > + } > > + > > +out: > > + rcu_read_unlock(); > > + return has_attrs; > > +} > > + > ... > > +/* Set @attributes for the gfn range [@start, @end). */ > > +static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attributes) > > +{ > > + struct kvm_mmu_notifier_range pre_set_range = { > > + .start = start, > > + .end = end, > > + .handler = kvm_arch_pre_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_begin, > > + .flush_on_ret = true, > > + .may_block = true, > > + }; > > + struct kvm_mmu_notifier_range post_set_range = { > > + .start = start, > > + .end = end, > > + .arg.attributes = attributes, > > + .handler = kvm_arch_post_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_end, > > + .may_block = true, > > + }; > > + unsigned long i; > > + void *entry; > > + int r = 0; > > + > > + entry = attributes ? xa_mk_value(attributes) : NULL; > Also here, do we need to get existing attributes of a GFN first ? No? @entry is the new value that will be set for all entries. This line doesn't touch the xarray in any way. Maybe I'm just not understanding your question. 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id CEBD8C05024 for ; Wed, 20 Sep 2023 21:00:38 +0000 (UTC) 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:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=H1f7jbR2ym5vC5rXJEeK/F16iWCS5TkWUAz3UhyEyPM=; b=GNLynzTkX+4QH5rVD+75eIWtCL CoQF15t13AMfBQdatnbutnGI6rDkm6qumaNHajwMknJXOzYIk+KTKMox4wW+agPKiwNVPrhjydXWp bPmY9L1MibrgfDim4a9u1HLh1DnQ0+DX+P1/7MtSYk08Ultuo2V1w/cyX5H8dmLEQi18SCsVUZEET IbSuLI9csEe1TILHfNixFIylIJNTFmu4YU9EwLwhwGNw9yNsRp8vMVIq2AvDqKbQNFic0sEbXArtl m6U7koEeAuVAss54AqUa5kwEyl2iSE+rddBLN+3MiPgQHogzxUtMEzpU3KXV0IK+EIiKSQIORnNIw uojuN1ow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qj4JB-004CLT-1g; Wed, 20 Sep 2023 21:00:29 +0000 Received: from mail-yb1-xb49.google.com ([2607:f8b0:4864:20::b49]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qj4J7-004CIh-2L for linux-riscv@lists.infradead.org; Wed, 20 Sep 2023 21:00:28 +0000 Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d81a47e12b5so447894276.0 for ; Wed, 20 Sep 2023 14:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695243624; x=1695848424; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=WD85YU6GCdPtOsLZeVlIeZZfzAYdtoOH/7wu6gyWXNI=; b=zVGBbf/3lyjQrGec6qqULc/ue0/Uzfoznp4oMroH1jakIT+C2oVWeq8ZeJYue9NY2A mdv4ozi4e0fRbN/UXWStxAD6GZCCGUFn/TS5L4Q7p8KyjbuVDxw69VHGJoI57YQc9kik TXXUQ88YgMO2818Ya8wwrDrt3B3/bF8lEdAuEzBdHHOt/nSDjyM3VaOjglnDt6rGrEVr jHPcA+y7hiUx5Te2ftEAoyn53EutLp0rz+w0YYRrfMfRrN69VekOq0uA3XxXlyLqFSia 3/KbqHPTpfVsChhEu1oZ4KwaHPn4rLmRDflnE3b6OPaxiuDEOAkatvtmnsv6BvtnMnoN NDeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695243624; x=1695848424; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WD85YU6GCdPtOsLZeVlIeZZfzAYdtoOH/7wu6gyWXNI=; b=CGxkhw5XtyrFOos1nw3RtXXJHVgX4KG62u1V5X/lh6OGyT8ZylAXCSOrUMmkJP89NO jbkRrqOYlVMLawfMYfAK1Tdh4ikiG4FhN2wQBNX2v0eOeXWKwjHTkD0Thqi7aHUPl8D4 vfU8XD953GbFcR4r1ux7IdwjeCY81ifLfsgqCLvepthWy50McbOUPKSVI0u3BZCBJtx0 MD2vQHMXf63vZmmKB93bzq9qO/k3PxRPSCzMRW/TWWbcbMptFs8vturWK98nAxRIDnq9 lAdKL0v8QnONR1zMY58Tx3wfYqXYHSmxlbtAmE2/gMZLaEwxalteQfkhD5XfDx4ocIjp shiA== X-Gm-Message-State: AOJu0Yz55YKN49jVuE894fAgM0RP/Qi+BIDA2VrXzAOKO/2ko6neWH30 qAvitMqUPLkCQwJi7srNSIFy+DOCLgQ= X-Google-Smtp-Source: AGHT+IE6bowhyf6hyHthYBPyW6IZfmwFxVZA3ErkF6QZibGvin1ESoG81Vf7MPhR8G5wDRxCxsmQT8EV7w4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:496:0:b0:d7f:2cb6:7d88 with SMTP id 144-20020a250496000000b00d7f2cb67d88mr58003ybe.13.1695243624102; Wed, 20 Sep 2023 14:00:24 -0700 (PDT) Date: Wed, 20 Sep 2023 14:00:22 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-12-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Yan Zhao Cc: 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 , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230920_140025_766854_2069EBF1 X-CRM114-Status: GOOD ( 19.11 ) X-BeenThere: linux-riscv@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-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Fri, Sep 15, 2023, Yan Zhao wrote: > On Wed, Sep 13, 2023 at 06:55:09PM -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. > > > ... > >> +bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attrs) > > +{ > > + XA_STATE(xas, &kvm->mem_attr_array, start); > > + unsigned long index; > > + bool has_attrs; > > + void *entry; > > + > > + rcu_read_lock(); > > + > > + if (!attrs) { > > + has_attrs = !xas_find(&xas, end); > > + goto out; > > + } > > + > > + has_attrs = true; > > + for (index = start; index < end; index++) { > > + do { > > + entry = xas_next(&xas); > > + } while (xas_retry(&xas, entry)); > > + > > + if (xas.xa_index != index || xa_to_value(entry) != attrs) { > Should "xa_to_value(entry) != attrs" be "!(xa_to_value(entry) & attrs)" ? No, the exact comparsion is deliberate. The intent of the API is to determine if the entire range already has the desired attributes, not if there is overlap between the two. E.g. if/when RWX attributes are supported, the exact comparison is needed to handle a RW => R conversion. > > + has_attrs = false; > > + break; > > + } > > + } > > + > > +out: > > + rcu_read_unlock(); > > + return has_attrs; > > +} > > + > ... > > +/* Set @attributes for the gfn range [@start, @end). */ > > +static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attributes) > > +{ > > + struct kvm_mmu_notifier_range pre_set_range = { > > + .start = start, > > + .end = end, > > + .handler = kvm_arch_pre_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_begin, > > + .flush_on_ret = true, > > + .may_block = true, > > + }; > > + struct kvm_mmu_notifier_range post_set_range = { > > + .start = start, > > + .end = end, > > + .arg.attributes = attributes, > > + .handler = kvm_arch_post_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_end, > > + .may_block = true, > > + }; > > + unsigned long i; > > + void *entry; > > + int r = 0; > > + > > + entry = attributes ? xa_mk_value(attributes) : NULL; > Also here, do we need to get existing attributes of a GFN first ? No? @entry is the new value that will be set for all entries. This line doesn't touch the xarray in any way. Maybe I'm just not understanding your question. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 86A0CC05024 for ; Wed, 20 Sep 2023 21:01:26 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=BpiPqpAj; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RrWD416BQz3cF2 for ; Thu, 21 Sep 2023 07:01:24 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=BpiPqpAj; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::b49; helo=mail-yb1-xb49.google.com; envelope-from=3af0lzqykdh8vhdqmfjrrjoh.frpolqx0ssf-ghyolvwv.r2odev.ruj@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4RrWC34mJVz303l for ; Thu, 21 Sep 2023 07:00:29 +1000 (AEST) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d818e01823aso422656276.2 for ; Wed, 20 Sep 2023 14:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695243624; x=1695848424; darn=lists.ozlabs.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=WD85YU6GCdPtOsLZeVlIeZZfzAYdtoOH/7wu6gyWXNI=; b=BpiPqpAj36hhv7mwWfIPnWHPfSBoVniJr0miM9XAkN6V0zGbGQ/fQcMzR0JDrcS03i N/GvH9V0yQ8sDe5Drn4z8NmmoFK3GwpQk4wjkJ+iyC0BfISBUQj3ElID9JnhFRjF7C+R CHHqiIxzYY9A/YffBUop6kwp29WX4g6iT71Uo2ueyDLLKgr7hJPWKRXHm9I8jn/jdLEA RIMRi2NcVrW+AIoxUiRBtTWjm97fZC6sPhMnpn6d7gzshc/nvTr4crBkmqyibgLSfyNr H7D4rhDOJThi04I7fmYg7cXSmY2IeaN79zySnvgIxBo78sjnHu5EynCMjhg9lVL/8xIH 11MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695243624; x=1695848424; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WD85YU6GCdPtOsLZeVlIeZZfzAYdtoOH/7wu6gyWXNI=; b=PHCs7YEI6DMYX9/qHes84apkrDe3YDfAzkIcKGUAQm81GXzmKxcUwtXSwj5wI8tIrQ OEWbmBMzZKQ116kKyf8ZChQQ7PlHhFBkt884BNJFHAmS0nd6voOp1alW1XQn2fI2yjQH mkaQRnJXnAIRnt1eBV4BTmRBVAU+h2qxE/7wF/GZPKpQi4HKq/Fyo9jEQHkLp7J6wyk8 glhNSavV2rea741wl0d0EM5wyE6PvAxrDKBzfDwt9M5aPSTFfCFBjw3WK5/FZsZbQV5q ypqUsqJ24ZroKjm9EJWVpUBpkw0HTzc77C5ERLatrb8Exfba7Y6zfxhy6fCeW8b1H9PR ZYlw== X-Gm-Message-State: AOJu0Yy8us4LMdkGhduxT9sPHkAL72ymmhWerlbOc3q9QuZOC9XB/3pP IVdti5w99+St3CMcYlH8MTYJrQRQyx4= X-Google-Smtp-Source: AGHT+IE6bowhyf6hyHthYBPyW6IZfmwFxVZA3ErkF6QZibGvin1ESoG81Vf7MPhR8G5wDRxCxsmQT8EV7w4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:496:0:b0:d7f:2cb6:7d88 with SMTP id 144-20020a250496000000b00d7f2cb67d88mr58003ybe.13.1695243624102; Wed, 20 Sep 2023 14:00:24 -0700 (PDT) Date: Wed, 20 Sep 2023 14:00:22 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-12-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Yan Zhao Content-Type: text/plain; charset="us-ascii" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, David Hildenbrand , Yu Zhang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chao Peng , linux-riscv@lists.infradead.org, Isaku Yamahata , Paul Moore , Marc Zyngier , Huacai Chen , James Morris , "Matthew Wilcox \(Oracle\)" , Wang , Fuad Tabba , Jarkko Sakkinen , "Serge E. Hallyn" , Maciej Szmigiero , Albert Ou , Vlastimil Babka , Michael Roth , Ackerley Tng , Paul Walmsley , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Isaku Yamahata , Quentin Perret , Liam Merwick , linux-mips@vger.kernel.org, Oliver Upton , linux-security-module@vger.kernel.org, Palmer Dabbelt , "Kirill A . Shutemov" , kvm-riscv@lists.infradead.org, Anup Patel , linux-fsdevel@vger.kernel.org, Paolo Bonzini , Andrew Morton , Vishal Annapurve , linuxppc-dev@lists.ozlabs.org, Xu Yilun , Anish Moorthy Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Sep 15, 2023, Yan Zhao wrote: > On Wed, Sep 13, 2023 at 06:55:09PM -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. > > > ... > >> +bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attrs) > > +{ > > + XA_STATE(xas, &kvm->mem_attr_array, start); > > + unsigned long index; > > + bool has_attrs; > > + void *entry; > > + > > + rcu_read_lock(); > > + > > + if (!attrs) { > > + has_attrs = !xas_find(&xas, end); > > + goto out; > > + } > > + > > + has_attrs = true; > > + for (index = start; index < end; index++) { > > + do { > > + entry = xas_next(&xas); > > + } while (xas_retry(&xas, entry)); > > + > > + if (xas.xa_index != index || xa_to_value(entry) != attrs) { > Should "xa_to_value(entry) != attrs" be "!(xa_to_value(entry) & attrs)" ? No, the exact comparsion is deliberate. The intent of the API is to determine if the entire range already has the desired attributes, not if there is overlap between the two. E.g. if/when RWX attributes are supported, the exact comparison is needed to handle a RW => R conversion. > > + has_attrs = false; > > + break; > > + } > > + } > > + > > +out: > > + rcu_read_unlock(); > > + return has_attrs; > > +} > > + > ... > > +/* Set @attributes for the gfn range [@start, @end). */ > > +static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attributes) > > +{ > > + struct kvm_mmu_notifier_range pre_set_range = { > > + .start = start, > > + .end = end, > > + .handler = kvm_arch_pre_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_begin, > > + .flush_on_ret = true, > > + .may_block = true, > > + }; > > + struct kvm_mmu_notifier_range post_set_range = { > > + .start = start, > > + .end = end, > > + .arg.attributes = attributes, > > + .handler = kvm_arch_post_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_end, > > + .may_block = true, > > + }; > > + unsigned long i; > > + void *entry; > > + int r = 0; > > + > > + entry = attributes ? xa_mk_value(attributes) : NULL; > Also here, do we need to get existing attributes of a GFN first ? No? @entry is the new value that will be set for all entries. This line doesn't touch the xarray in any way. Maybe I'm just not understanding your question. 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 2E370C05025 for ; Wed, 20 Sep 2023 21:00:52 +0000 (UTC) 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:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=yxcB00f3UQkJJaDRwEAQNMQiQVmILOsnajx3CKFnyjc=; b=gj8LPX5hNJTEI2aIGgwCuoWyvk Ksg9lfbuQiQH4ZjKuFX+M63cG3hvpufSyklpbWV4NA/QfjmXs0UelkYmVTggVeXP4ingIPphmNXIw N9Sn/HTJ/qi06qPC7Za6/b8uCEyVtmd106E+p5MkS+uS4Hx1YNbhe4dy3zvzutEOSlco4O44EreY1 QIT2pNoRnEdtBVt/kdfwPwZCIsOSrJGGqDhogkiHxL/SvkYM4pO/Y9aTyAuGf6E3SaEHO6rl9zFXC G9Xy3+O3510tNTMIV4UpVnv+epfuFe6X36VA1NWVWxzrLslZh/Eu658IhkbbOiDydPbllavYtat9H kIDwcVgA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qj4JA-004CKT-1V; Wed, 20 Sep 2023 21:00:28 +0000 Received: from mail-yb1-xb49.google.com ([2607:f8b0:4864:20::b49]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qj4J7-004CId-1q for linux-arm-kernel@lists.infradead.org; Wed, 20 Sep 2023 21:00:27 +0000 Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d8186d705a9so421043276.3 for ; Wed, 20 Sep 2023 14:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695243624; x=1695848424; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=WD85YU6GCdPtOsLZeVlIeZZfzAYdtoOH/7wu6gyWXNI=; b=zVGBbf/3lyjQrGec6qqULc/ue0/Uzfoznp4oMroH1jakIT+C2oVWeq8ZeJYue9NY2A mdv4ozi4e0fRbN/UXWStxAD6GZCCGUFn/TS5L4Q7p8KyjbuVDxw69VHGJoI57YQc9kik TXXUQ88YgMO2818Ya8wwrDrt3B3/bF8lEdAuEzBdHHOt/nSDjyM3VaOjglnDt6rGrEVr jHPcA+y7hiUx5Te2ftEAoyn53EutLp0rz+w0YYRrfMfRrN69VekOq0uA3XxXlyLqFSia 3/KbqHPTpfVsChhEu1oZ4KwaHPn4rLmRDflnE3b6OPaxiuDEOAkatvtmnsv6BvtnMnoN NDeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695243624; x=1695848424; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WD85YU6GCdPtOsLZeVlIeZZfzAYdtoOH/7wu6gyWXNI=; b=pxLR/w9RoVrRif+oQ2Vp6N5mUFmEISGui0GEtnb4nVCDpPNKWFV8qNcrWMrxmgRt1e It4ipUY3xD/FLBsc/ldOAM/854iUArj8toj+uuWNZ2e4KkJJpN3sCGpfsIrKTIvBOtER AmK9fCjCem94FEWRz+IlCntbMKivkg36SBDbl7dimJotUydRAYQytlfE9Bshm0mWrcxI UuQ3t+/ls3ENmZdOMLklLai4bP/FYBmociyHJONCcK5LkVNC3O3aXUZEuNOOp4/15Hm9 ocL5cjDsajErl/ZEM6iZGmI6nOlgWN5wJc+EEGddAgj8/rpIGQ1VsweJ/ca6kmp6roDZ 9iFg== X-Gm-Message-State: AOJu0YxnF8Mb18cieuAGMTwvjMD+pjdWNxMwe2IXfaagPh4I2aRo1Nlf tKOvxCadoKA0a9Qcz68CYEp91540Jzo= X-Google-Smtp-Source: AGHT+IE6bowhyf6hyHthYBPyW6IZfmwFxVZA3ErkF6QZibGvin1ESoG81Vf7MPhR8G5wDRxCxsmQT8EV7w4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:496:0:b0:d7f:2cb6:7d88 with SMTP id 144-20020a250496000000b00d7f2cb67d88mr58003ybe.13.1695243624102; Wed, 20 Sep 2023 14:00:24 -0700 (PDT) Date: Wed, 20 Sep 2023 14:00:22 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-12-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 11/33] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Yan Zhao Cc: 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 , Anish Moorthy , Yu Zhang , Isaku Yamahata , Xu Yilun , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230920_140025_631442_5C656A68 X-CRM114-Status: GOOD ( 20.74 ) 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 Fri, Sep 15, 2023, Yan Zhao wrote: > On Wed, Sep 13, 2023 at 06:55:09PM -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. > > > ... > >> +bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attrs) > > +{ > > + XA_STATE(xas, &kvm->mem_attr_array, start); > > + unsigned long index; > > + bool has_attrs; > > + void *entry; > > + > > + rcu_read_lock(); > > + > > + if (!attrs) { > > + has_attrs = !xas_find(&xas, end); > > + goto out; > > + } > > + > > + has_attrs = true; > > + for (index = start; index < end; index++) { > > + do { > > + entry = xas_next(&xas); > > + } while (xas_retry(&xas, entry)); > > + > > + if (xas.xa_index != index || xa_to_value(entry) != attrs) { > Should "xa_to_value(entry) != attrs" be "!(xa_to_value(entry) & attrs)" ? No, the exact comparsion is deliberate. The intent of the API is to determine if the entire range already has the desired attributes, not if there is overlap between the two. E.g. if/when RWX attributes are supported, the exact comparison is needed to handle a RW => R conversion. > > + has_attrs = false; > > + break; > > + } > > + } > > + > > +out: > > + rcu_read_unlock(); > > + return has_attrs; > > +} > > + > ... > > +/* Set @attributes for the gfn range [@start, @end). */ > > +static int kvm_vm_set_mem_attributes(struct kvm *kvm, gfn_t start, gfn_t end, > > + unsigned long attributes) > > +{ > > + struct kvm_mmu_notifier_range pre_set_range = { > > + .start = start, > > + .end = end, > > + .handler = kvm_arch_pre_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_begin, > > + .flush_on_ret = true, > > + .may_block = true, > > + }; > > + struct kvm_mmu_notifier_range post_set_range = { > > + .start = start, > > + .end = end, > > + .arg.attributes = attributes, > > + .handler = kvm_arch_post_set_memory_attributes, > > + .on_lock = kvm_mmu_invalidate_end, > > + .may_block = true, > > + }; > > + unsigned long i; > > + void *entry; > > + int r = 0; > > + > > + entry = attributes ? xa_mk_value(attributes) : NULL; > Also here, do we need to get existing attributes of a GFN first ? No? @entry is the new value that will be set for all entries. This line doesn't touch the xarray in any way. Maybe I'm just not understanding your question. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel