From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Mon, 30 Oct 2023 15:05:56 -0700 Subject: [PATCH v13 13/35] KVM: Introduce per-page memory attributes In-Reply-To: References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-14-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 Mon, Oct 30, 2023, Sean Christopherson wrote: > On Mon, Oct 30, 2023, Chao Gao wrote: > > On Fri, Oct 27, 2023 at 11:21:55AM -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. > > > > This ioctl() is already removed. So, the changelog is out-of-date and needs > > an update. > > Doh, I lost track of this and the fixup for KVM_CAP_MEMORY_ATTRIBUTES below. > > > >+:Capability: KVM_CAP_MEMORY_ATTRIBUTES > > >+:Architectures: x86 > > >+:Type: vm ioctl > > >+:Parameters: struct kvm_memory_attributes(in) > > > > ^ add one space here? > > Ah, yeah, that does appear to be the standard. > > > > > > >+static bool kvm_pre_set_memory_attributes(struct kvm *kvm, > > >+ struct kvm_gfn_range *range) > > >+{ > > >+ /* > > >+ * Unconditionally add the range to the invalidation set, regardless of > > >+ * whether or not the arch callback actually needs to zap SPTEs. E.g. > > >+ * if KVM supports RWX attributes in the future and the attributes are > > >+ * going from R=>RW, zapping isn't strictly necessary. Unconditionally > > >+ * adding the range allows KVM to require that MMU invalidations add at > > >+ * least one range between begin() and end(), e.g. allows KVM to detect > > >+ * bugs where the add() is missed. Rexlaing the rule *might* be safe, > > > > ^^^^^^^^ Relaxing > > > > >@@ -4640,6 +4850,17 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > > case KVM_CAP_BINARY_STATS_FD: > > > case KVM_CAP_SYSTEM_EVENT_DATA: > > > return 1; > > >+#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > >+ case KVM_CAP_MEMORY_ATTRIBUTES: > > >+ u64 attrs = kvm_supported_mem_attributes(kvm); > > >+ > > >+ r = -EFAULT; > > >+ if (copy_to_user(argp, &attrs, sizeof(attrs))) > > >+ goto out; > > >+ r = 0; > > >+ break; > > > > This cannot work, e.g., no @argp in this function and is fixed by a later commit: > > > > fcbef1e5e5d2 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") > > I'll post a fixup patch for all of these, thanks much! Heh, that was an -ENOCOFFEE. Fixup patches for a changelog goof and an ephemeral bug are going to be hard to post. Paolo, do you want to take care of all of these fixups and typos, or would you prefer that I start a v14 branch and then hand it off to you at some point? 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 90F6E1C6A0 for ; Mon, 30 Oct 2023 22:05:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="yVkj0y5T" Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-d99ec34829aso4546193276.1 for ; Mon, 30 Oct 2023 15:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698703558; x=1699308358; 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=1IwVDVsbZSN9+qsHUIXJ8IN4aMaIP7o7r0dMzi80JWo=; b=yVkj0y5TfOSQoePqHTSx+vjwqRuCFqdzcr6X2kDqGdBKewL7piHotBbdhBgfBvKtCj BNXeg4KUU23iuMTZCuL776QTFw1GmB0gLbUd3MVwrjVeY63Rb0dWd5nJiPg6IiZ3BOns AyPDpBba/i5XX0kV7SJNBpf/zTzcyGrQmLhJD+IzZru0rW5BxklnXls+TJfxNiWeiEmr rBGx8yv1zLuLJSm10CVlnemBgOhg1nyCTEzBqKintSOKBx74CM7WVGHSwL/EQY9EpaEH twj8cLoAP2mGm4FdQelJVA7WhijAZ+4GnbbeYj2jy35NkaZOGU6jmuVZBTF4N9pM8Vds naZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698703558; x=1699308358; 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=1IwVDVsbZSN9+qsHUIXJ8IN4aMaIP7o7r0dMzi80JWo=; b=IHZcZhuVIsl2Rmq9ZbKi780ucgikAx+co1MrexLUa1fGQqqUtnGmfWZYLAvNYpXohl REW6V+XEV06m+R2DgRXIK0YUkH1rUwxJIXHXPVzkBBKb9/qGALQsL3OYJsf8uC3CAHlM obd66Cz25+0Vebyb4hPVFuWDabkJMY9FnwUW3mKZKD+d/NqLMah/ngHi7gt1y6mX4zZY AO0PAgujqiPAPdVaFgMxa4W1eKOL8BlCL4UdtOwhli3GMC3H6/gxTYAgA1/m2vQD0L0R dpAKlhEiMNoBUE3Z5y9V4ulCVK+J76600FB63mSdPiUvwTM2nsAyUghJUYdbhM4bR0y+ Sp+Q== X-Gm-Message-State: AOJu0YxYg2ktbothmIyv0PEbtGkPl0r2nevS3kyllkhpWvnU0Pn5NCz9 FzDcrI5w3bTIFD2ZiEMMT6Ms7GPVd0s= X-Google-Smtp-Source: AGHT+IEdUnGiaB+HWnyvBXIWgJEvc4p4Jj6o8XAknp5F2BcjElHvOjmW/sQ9BadeZP3HZD1+EeGEwSi+J0Q= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:b108:0:b0:d99:3750:d607 with SMTP id g8-20020a25b108000000b00d993750d607mr203752ybj.8.1698703558464; Mon, 30 Oct 2023 15:05:58 -0700 (PDT) Date: Mon, 30 Oct 2023 15:05:56 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-14-seanjc@google.com> Message-ID: Subject: Re: [PATCH v13 13/35] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Chao Gao Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexander Viro , Christian Brauner , "Matthew Wilcox (Oracle)" , Andrew Morton , 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-kernel@vger.kernel.org, Xiaoyao Li , Xu Yilun , Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , David Matlack , Yu Zhang , Isaku Yamahata , "=?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?=" , 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 Mon, Oct 30, 2023, Sean Christopherson wrote: > On Mon, Oct 30, 2023, Chao Gao wrote: > > On Fri, Oct 27, 2023 at 11:21:55AM -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. > > > > This ioctl() is already removed. So, the changelog is out-of-date and needs > > an update. > > Doh, I lost track of this and the fixup for KVM_CAP_MEMORY_ATTRIBUTES below. > > > >+:Capability: KVM_CAP_MEMORY_ATTRIBUTES > > >+:Architectures: x86 > > >+:Type: vm ioctl > > >+:Parameters: struct kvm_memory_attributes(in) > > > > ^ add one space here? > > Ah, yeah, that does appear to be the standard. > > > > > > >+static bool kvm_pre_set_memory_attributes(struct kvm *kvm, > > >+ struct kvm_gfn_range *range) > > >+{ > > >+ /* > > >+ * Unconditionally add the range to the invalidation set, regardless of > > >+ * whether or not the arch callback actually needs to zap SPTEs. E.g. > > >+ * if KVM supports RWX attributes in the future and the attributes are > > >+ * going from R=>RW, zapping isn't strictly necessary. Unconditionally > > >+ * adding the range allows KVM to require that MMU invalidations add at > > >+ * least one range between begin() and end(), e.g. allows KVM to detect > > >+ * bugs where the add() is missed. Rexlaing the rule *might* be safe, > > > > ^^^^^^^^ Relaxing > > > > >@@ -4640,6 +4850,17 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > > case KVM_CAP_BINARY_STATS_FD: > > > case KVM_CAP_SYSTEM_EVENT_DATA: > > > return 1; > > >+#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > >+ case KVM_CAP_MEMORY_ATTRIBUTES: > > >+ u64 attrs = kvm_supported_mem_attributes(kvm); > > >+ > > >+ r = -EFAULT; > > >+ if (copy_to_user(argp, &attrs, sizeof(attrs))) > > >+ goto out; > > >+ r = 0; > > >+ break; > > > > This cannot work, e.g., no @argp in this function and is fixed by a later commit: > > > > fcbef1e5e5d2 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") > > I'll post a fixup patch for all of these, thanks much! Heh, that was an -ENOCOFFEE. Fixup patches for a changelog goof and an ephemeral bug are going to be hard to post. Paolo, do you want to take care of all of these fixups and typos, or would you prefer that I start a v14 branch and then hand it off to you at some point? 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 D2E45C4332F for ; Mon, 30 Oct 2023 22:06:16 +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=BgDkUvMiwFCtxwIDtnJ9Ujhnyuhyi4WDzHxIYKO+0ig=; b=nQtYvCr9w/W7piz3c1E2+Z/rwA Q3dMvJ3AXkXQO8DYiaFifhNrArt+EBox79Mib0sxpaHm8BIf5nZyEtYIUUQ6R5pz+ICL7tTWF1yAE RDdGeyHZzsATPt/lsopsNS3fjmeTVhpMC07yNYqBiQFPNDReISrULNGhc3iylU1w+mhBZcIVzlCcn GCK/1U1afn+8p9DRXtqsg5DjbcWgekqbwqBCrFoCHy7W0vFJ/7jMBpks/ROoVALT9UIhJ3F2PTJwH eXxqELQVhH8k6LVqjNYcUkTZRVvloDthjx3WgQiskbaOgzgoCpvvvrbCG0OKWcLoBd4Il/JPHZG3r N6X8nppg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qxaOZ-0046mv-1b; Mon, 30 Oct 2023 22:06:03 +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 1qxaOX-0046lp-00 for linux-riscv@lists.infradead.org; Mon, 30 Oct 2023 22:06:02 +0000 Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d99ec34829aso4546198276.1 for ; Mon, 30 Oct 2023 15:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698703558; x=1699308358; 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=1IwVDVsbZSN9+qsHUIXJ8IN4aMaIP7o7r0dMzi80JWo=; b=w5dXSfF58XY5WXDH5t9VULsoh77JHLMPwYQuS9pHNJ9mj1JYBQSMXR2qRXrtr2p1V2 R6kTYvMjiTw/5x3ur8Esbt3DmcTXy1ahXLL6LiAgz7idrKgfqbF7jVRaBii2CRefL3Jj UrSDDlxkiGqC6qpOUmIXVGO6Dyr0xRiOUSBq1xXjBiweq6BNTWZbfJTZbGYeTpjJQPcQ f9PiyhLleAcFKTVWNceqK8oZ4tKMV8KwkqDCIsHG5b65RG6xl2IsC6T20JSCWR+Z03ft 0SknfA+919oVXtcKyzZaZNK1ajSTBGB81U1UXY9fUcTvppSxaC4LXcralv3aRG3Dxtnw heyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698703558; x=1699308358; 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=1IwVDVsbZSN9+qsHUIXJ8IN4aMaIP7o7r0dMzi80JWo=; b=pi6STdxXnpMrih0e7AlD51YbjYPD82TeccAUZjm6uE9xm4QOPPDHRMDHwLIqZDYkKh Vwm6rHJN3Q9IU3rxfdvXE5wUYmmHZEobllYDZ5v+ZEZKBN++ILpr1K8Btfab7PAkSUyQ 3kSJirzBPEecUoqzS8Cqm2KyTQ1gXWTzIUtaPEBcQtb91SQoQlDbzM/U54M8I6SorOiv ZVN7Gn8A2pv8x5RP8bIhPVuYWzDEJnoFDXbCiU3YLuuUtX9KJiEDOH9NToy3zK5/9V0d vWC17cf9z8B0aTcXcQ5gslL9iPis8r1ZHDUgjs/dxf3FIFIKTc8OZQkX63cFODC94mn/ yuPw== X-Gm-Message-State: AOJu0Yz0BeR99T44BCAWV81CHld/8cDfxCdTzQxxHOSq/uQ73GzegXqp Mg+2MCevyAuGeWTF9AR8youAXtVgwrs= X-Google-Smtp-Source: AGHT+IEdUnGiaB+HWnyvBXIWgJEvc4p4Jj6o8XAknp5F2BcjElHvOjmW/sQ9BadeZP3HZD1+EeGEwSi+J0Q= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:b108:0:b0:d99:3750:d607 with SMTP id g8-20020a25b108000000b00d993750d607mr203752ybj.8.1698703558464; Mon, 30 Oct 2023 15:05:58 -0700 (PDT) Date: Mon, 30 Oct 2023 15:05:56 -0700 In-Reply-To: Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-14-seanjc@google.com> Message-ID: Subject: Re: [PATCH v13 13/35] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Chao Gao Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexander Viro , Christian Brauner , "Matthew Wilcox (Oracle)" , Andrew Morton , 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-kernel@vger.kernel.org, Xiaoyao Li , Xu Yilun , Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , David Matlack , Yu Zhang , Isaku Yamahata , "=?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?=" , 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-20231030_150601_039718_F1329B61 X-CRM114-Status: GOOD ( 23.67 ) 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 Mon, Oct 30, 2023, Sean Christopherson wrote: > On Mon, Oct 30, 2023, Chao Gao wrote: > > On Fri, Oct 27, 2023 at 11:21:55AM -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. > > > > This ioctl() is already removed. So, the changelog is out-of-date and needs > > an update. > > Doh, I lost track of this and the fixup for KVM_CAP_MEMORY_ATTRIBUTES below. > > > >+:Capability: KVM_CAP_MEMORY_ATTRIBUTES > > >+:Architectures: x86 > > >+:Type: vm ioctl > > >+:Parameters: struct kvm_memory_attributes(in) > > > > ^ add one space here? > > Ah, yeah, that does appear to be the standard. > > > > > > >+static bool kvm_pre_set_memory_attributes(struct kvm *kvm, > > >+ struct kvm_gfn_range *range) > > >+{ > > >+ /* > > >+ * Unconditionally add the range to the invalidation set, regardless of > > >+ * whether or not the arch callback actually needs to zap SPTEs. E.g. > > >+ * if KVM supports RWX attributes in the future and the attributes are > > >+ * going from R=>RW, zapping isn't strictly necessary. Unconditionally > > >+ * adding the range allows KVM to require that MMU invalidations add at > > >+ * least one range between begin() and end(), e.g. allows KVM to detect > > >+ * bugs where the add() is missed. Rexlaing the rule *might* be safe, > > > > ^^^^^^^^ Relaxing > > > > >@@ -4640,6 +4850,17 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > > case KVM_CAP_BINARY_STATS_FD: > > > case KVM_CAP_SYSTEM_EVENT_DATA: > > > return 1; > > >+#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > >+ case KVM_CAP_MEMORY_ATTRIBUTES: > > >+ u64 attrs = kvm_supported_mem_attributes(kvm); > > >+ > > >+ r = -EFAULT; > > >+ if (copy_to_user(argp, &attrs, sizeof(attrs))) > > >+ goto out; > > >+ r = 0; > > >+ break; > > > > This cannot work, e.g., no @argp in this function and is fixed by a later commit: > > > > fcbef1e5e5d2 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") > > I'll post a fixup patch for all of these, thanks much! Heh, that was an -ENOCOFFEE. Fixup patches for a changelog goof and an ephemeral bug are going to be hard to post. Paolo, do you want to take care of all of these fixups and typos, or would you prefer that I start a v14 branch and then hand it off to you at some point? _______________________________________________ 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 775B4C4332F for ; Mon, 30 Oct 2023 22:06:58 +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=vy01LS0j; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4SK6nD6qXHz3cW1 for ; Tue, 31 Oct 2023 09:06:56 +1100 (AEDT) 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=vy01LS0j; 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::114a; helo=mail-yw1-x114a.google.com; envelope-from=3xihazqykdek3plyunrzzrwp.nzxwty5800n-op6wt343.zawlm3.z2r@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) (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 4SK6mF4BQnz3bXH for ; Tue, 31 Oct 2023 09:06:03 +1100 (AEDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5af9b0850fdso43633077b3.1 for ; Mon, 30 Oct 2023 15:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698703558; x=1699308358; 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=1IwVDVsbZSN9+qsHUIXJ8IN4aMaIP7o7r0dMzi80JWo=; b=vy01LS0jfiJKLmmKpkSzUVJ/pcSP7m9SiVySLWbyQIqjXFmoewG+EuRKsBmvISCqmd +F777UYvT0UV5vh0UHLJIBPjuTs4REgswcEjnUBOlCwcn42I5rIsGUL56R2T8RrRD3Dy N5gj28d5t7ueVJye3pAa+fqX2miOqdjv1KjctYSE/+gLfzneOnXBj12XHWtafHw9I9Dy jv3sIg4OJPH9Fh0d+++aG2Z7k49PmjUuBjZ+miAgAIs3UkqeAUIL0LR4XfnlDt7zt3I3 oMTc/4aiDvg4ckbk3gykSiuOw9owyt723TShXheOAOt4z6zp3Xu0z9ZODpnXT/6EZ4pR 3gWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698703558; x=1699308358; 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=1IwVDVsbZSN9+qsHUIXJ8IN4aMaIP7o7r0dMzi80JWo=; b=ngv+Wl41Wvi6jfwnCCWLHJjK5PyNg9ugOrp2Kd4Ky8s5DmQTDlwV0YxIB3qe/fP+HX ++FiIHuX3NGcIV9Fh61mgAdQgXPNKJM2zWeZ7+SyuX8KoeZFpb1QbiN6xIZIoMSU6ZyJ G6fAIgScfOHwe5Ycg36BfwDsHIjmOsl/uZhoKPnYXL//GyWIJyeokDzsvKkI9oIiT7cw Zd2j8zUM9eo7Ceb2ncgsKye954TX9Z3jm/SeMLXxHLecQgWE+jd11p8wWtih7kHxMVK7 +Oo1S/zMuem/ZOiWPCizG/aMXLfXBL1ovOyVekpiIh/3cNLxennPxbppmtkophIQ+7T2 RuVA== X-Gm-Message-State: AOJu0Ywh4dRATc71MNBzWHPKR4N2cESqU0WcMSoqu5DSnD4crox7YaGm OZBITKyb3JCACUz0qXiM2TeHdQhMHKs= X-Google-Smtp-Source: AGHT+IEdUnGiaB+HWnyvBXIWgJEvc4p4Jj6o8XAknp5F2BcjElHvOjmW/sQ9BadeZP3HZD1+EeGEwSi+J0Q= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:b108:0:b0:d99:3750:d607 with SMTP id g8-20020a25b108000000b00d993750d607mr203752ybj.8.1698703558464; Mon, 30 Oct 2023 15:05:58 -0700 (PDT) Date: Mon, 30 Oct 2023 15:05:56 -0700 In-Reply-To: Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-14-seanjc@google.com> Message-ID: Subject: Re: [PATCH v13 13/35] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Chao Gao 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 , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chao Peng , linux-riscv@lists.infradead.org, Isaku Yamahata , Marc Zyngier , Huacai Chen , Xiaoyao Li , "Matthew Wilcox \(Oracle\)" , Wang , Fuad Tabba , Yu Zhang , Maciej Szmigiero , Albert Ou , Vlastimil Babka , Michael Roth , Ackerley Tng , Alexander Viro , Paul Walmsley , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Isaku Yamahata , Christian Brauner , Quentin Perret , L iam Merwick , linux-mips@vger.kernel.org, Oliver Upton , David Matlack , Jarkko Sakkinen , 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 Mon, Oct 30, 2023, Sean Christopherson wrote: > On Mon, Oct 30, 2023, Chao Gao wrote: > > On Fri, Oct 27, 2023 at 11:21:55AM -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. > > > > This ioctl() is already removed. So, the changelog is out-of-date and needs > > an update. > > Doh, I lost track of this and the fixup for KVM_CAP_MEMORY_ATTRIBUTES below. > > > >+:Capability: KVM_CAP_MEMORY_ATTRIBUTES > > >+:Architectures: x86 > > >+:Type: vm ioctl > > >+:Parameters: struct kvm_memory_attributes(in) > > > > ^ add one space here? > > Ah, yeah, that does appear to be the standard. > > > > > > >+static bool kvm_pre_set_memory_attributes(struct kvm *kvm, > > >+ struct kvm_gfn_range *range) > > >+{ > > >+ /* > > >+ * Unconditionally add the range to the invalidation set, regardless of > > >+ * whether or not the arch callback actually needs to zap SPTEs. E.g. > > >+ * if KVM supports RWX attributes in the future and the attributes are > > >+ * going from R=>RW, zapping isn't strictly necessary. Unconditionally > > >+ * adding the range allows KVM to require that MMU invalidations add at > > >+ * least one range between begin() and end(), e.g. allows KVM to detect > > >+ * bugs where the add() is missed. Rexlaing the rule *might* be safe, > > > > ^^^^^^^^ Relaxing > > > > >@@ -4640,6 +4850,17 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > > case KVM_CAP_BINARY_STATS_FD: > > > case KVM_CAP_SYSTEM_EVENT_DATA: > > > return 1; > > >+#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > >+ case KVM_CAP_MEMORY_ATTRIBUTES: > > >+ u64 attrs = kvm_supported_mem_attributes(kvm); > > >+ > > >+ r = -EFAULT; > > >+ if (copy_to_user(argp, &attrs, sizeof(attrs))) > > >+ goto out; > > >+ r = 0; > > >+ break; > > > > This cannot work, e.g., no @argp in this function and is fixed by a later commit: > > > > fcbef1e5e5d2 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") > > I'll post a fixup patch for all of these, thanks much! Heh, that was an -ENOCOFFEE. Fixup patches for a changelog goof and an ephemeral bug are going to be hard to post. Paolo, do you want to take care of all of these fixups and typos, or would you prefer that I start a v14 branch and then hand it off to you at some point? 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 48BD5C4332F for ; Mon, 30 Oct 2023 22:06:35 +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=CkzTIm6zvIFeyOZlvSajeUrjqfqQWG30J87WoPIQji0=; b=pkNWi+y60byE0Wuan5mKGxHRKW LPLs+EEzfU51qa6yV5jis8VsEne7u12PGeciLAX5pSMubcizFgOXanzSdoJAbeyB69WfP3NjP9JH9 OSI0dMkwG5N8O7qqMER1/C9TDBkp8JOnhCvQXNY6eWvSql6soNwtBy0dAPDdkhnqv9DnYlXZRtxmC 0JQprYdpA65BDhbqOSE9vybsPHt9xCU//atm0O1xZxs5tU6UNoJuEIeP2LdL/4ix1rcnvLAAcXrob C8YeXiV1p2K5vh1tfAdq5w2bgBbtgeJkE1qtmOIEut0+QYzef5BI3S+lxLg5G5Rj4HWj1dNkxUtb4 OIU0stEg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qxaOa-0046n4-0O; Mon, 30 Oct 2023 22:06:04 +0000 Received: from mail-yw1-x114a.google.com ([2607:f8b0:4864:20::114a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qxaOW-0046lq-2e for linux-arm-kernel@lists.infradead.org; Mon, 30 Oct 2023 22:06:02 +0000 Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5a7ed6903a6so54127657b3.2 for ; Mon, 30 Oct 2023 15:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698703558; x=1699308358; 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=1IwVDVsbZSN9+qsHUIXJ8IN4aMaIP7o7r0dMzi80JWo=; b=w5dXSfF58XY5WXDH5t9VULsoh77JHLMPwYQuS9pHNJ9mj1JYBQSMXR2qRXrtr2p1V2 R6kTYvMjiTw/5x3ur8Esbt3DmcTXy1ahXLL6LiAgz7idrKgfqbF7jVRaBii2CRefL3Jj UrSDDlxkiGqC6qpOUmIXVGO6Dyr0xRiOUSBq1xXjBiweq6BNTWZbfJTZbGYeTpjJQPcQ f9PiyhLleAcFKTVWNceqK8oZ4tKMV8KwkqDCIsHG5b65RG6xl2IsC6T20JSCWR+Z03ft 0SknfA+919oVXtcKyzZaZNK1ajSTBGB81U1UXY9fUcTvppSxaC4LXcralv3aRG3Dxtnw heyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698703558; x=1699308358; 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=1IwVDVsbZSN9+qsHUIXJ8IN4aMaIP7o7r0dMzi80JWo=; b=KjvJ9+DirUcMxPhSZfEs3bhOd/vyWrB/QkWzKP4aYM23yt3UL6mncIJQOiOUk/wmpL oyaecF2nQ1cK0ijMh0U+FMju/S+exAk8WIoZ+HBB7smLmytT4YwghmUPP4KH9n4ZY1fu edR8I/Pp+3kbQHHUdDLFxKNU5hKoWGN3aW6SAzi/oYrB6qCpaXs3xLf5RAHXOofqONMK 1yZDAqRC3McgkZkJuwL6mx31AsIh70qJIAhZuIOQnRhKr7HYBzIRKMyqPDKdPFARxCGk MYj6driOtNb0SsqhahfouzKTzV6M5E0ySAeSusQZwklKtwwb37zReeLWPnk0CuHESp45 9ZCw== X-Gm-Message-State: AOJu0YxPu24Du8LukIkE7DsqdsrDiCMX9Me3iqRCD/zWIcdG2TCS8W3Y vW26bPJ8BqtTKEtNakdpT9n/g0Wwaqw= X-Google-Smtp-Source: AGHT+IEdUnGiaB+HWnyvBXIWgJEvc4p4Jj6o8XAknp5F2BcjElHvOjmW/sQ9BadeZP3HZD1+EeGEwSi+J0Q= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:b108:0:b0:d99:3750:d607 with SMTP id g8-20020a25b108000000b00d993750d607mr203752ybj.8.1698703558464; Mon, 30 Oct 2023 15:05:58 -0700 (PDT) Date: Mon, 30 Oct 2023 15:05:56 -0700 In-Reply-To: Mime-Version: 1.0 References: <20231027182217.3615211-1-seanjc@google.com> <20231027182217.3615211-14-seanjc@google.com> Message-ID: Subject: Re: [PATCH v13 13/35] KVM: Introduce per-page memory attributes From: Sean Christopherson To: Chao Gao Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexander Viro , Christian Brauner , "Matthew Wilcox (Oracle)" , Andrew Morton , 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-kernel@vger.kernel.org, Xiaoyao Li , Xu Yilun , Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , David Matlack , Yu Zhang , Isaku Yamahata , "=?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?=" , 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-20231030_150600_883163_07B407EA X-CRM114-Status: GOOD ( 25.19 ) 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, Oct 30, 2023, Sean Christopherson wrote: > On Mon, Oct 30, 2023, Chao Gao wrote: > > On Fri, Oct 27, 2023 at 11:21:55AM -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. > > > > This ioctl() is already removed. So, the changelog is out-of-date and needs > > an update. > > Doh, I lost track of this and the fixup for KVM_CAP_MEMORY_ATTRIBUTES below. > > > >+:Capability: KVM_CAP_MEMORY_ATTRIBUTES > > >+:Architectures: x86 > > >+:Type: vm ioctl > > >+:Parameters: struct kvm_memory_attributes(in) > > > > ^ add one space here? > > Ah, yeah, that does appear to be the standard. > > > > > > >+static bool kvm_pre_set_memory_attributes(struct kvm *kvm, > > >+ struct kvm_gfn_range *range) > > >+{ > > >+ /* > > >+ * Unconditionally add the range to the invalidation set, regardless of > > >+ * whether or not the arch callback actually needs to zap SPTEs. E.g. > > >+ * if KVM supports RWX attributes in the future and the attributes are > > >+ * going from R=>RW, zapping isn't strictly necessary. Unconditionally > > >+ * adding the range allows KVM to require that MMU invalidations add at > > >+ * least one range between begin() and end(), e.g. allows KVM to detect > > >+ * bugs where the add() is missed. Rexlaing the rule *might* be safe, > > > > ^^^^^^^^ Relaxing > > > > >@@ -4640,6 +4850,17 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > > case KVM_CAP_BINARY_STATS_FD: > > > case KVM_CAP_SYSTEM_EVENT_DATA: > > > return 1; > > >+#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > >+ case KVM_CAP_MEMORY_ATTRIBUTES: > > >+ u64 attrs = kvm_supported_mem_attributes(kvm); > > >+ > > >+ r = -EFAULT; > > >+ if (copy_to_user(argp, &attrs, sizeof(attrs))) > > >+ goto out; > > >+ r = 0; > > >+ break; > > > > This cannot work, e.g., no @argp in this function and is fixed by a later commit: > > > > fcbef1e5e5d2 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory") > > I'll post a fixup patch for all of these, thanks much! Heh, that was an -ENOCOFFEE. Fixup patches for a changelog goof and an ephemeral bug are going to be hard to post. Paolo, do you want to take care of all of these fixups and typos, or would you prefer that I start a v14 branch and then hand it off to you at some point? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel