From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Fri, 10 Nov 2023 10:22:59 -0800 Subject: [PATCH 15/34] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory In-Reply-To: <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.com> References: <20231105163040.14904-1-pbonzini@redhat.com> <20231105163040.14904-16-pbonzini@redhat.com> <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.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, Nov 10, 2023, Xiaoyao Li wrote: > On 11/6/2023 12:30 AM, Paolo Bonzini wrote: > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index 68a144cb7dbc..a6de526c0426 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@ -589,8 +589,20 @@ struct kvm_memory_slot { > > u32 flags; > > short id; > > u16 as_id; > > + > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + struct { > > + struct file __rcu *file; > > + pgoff_t pgoff; > > + } gmem; > > +#endif > > }; > > +static inline bool kvm_slot_can_be_private(const struct kvm_memory_slot *slot) > > +{ > > + return slot && (slot->flags & KVM_MEM_GUEST_MEMFD); > > +} > > + > > maybe we can move this block and ... > > > > > @@ -2355,6 +2379,30 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > bool kvm_arch_post_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > + > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM) && > > + kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE; > > +} > > +#else > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return false; > > +} > > #endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */ > > this block to Patch 18? It would work, but my vote is to keep them here to minimize the changes to common KVM code in the x86 enabling. It's not a strong preference though. Of course, at this point, fiddling with this sort of thing is probably a bad idea in terms of landing guest_memfd. > > @@ -4844,6 +4875,10 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > case KVM_CAP_MEMORY_ATTRIBUTES: > > return kvm_supported_mem_attributes(kvm); > > +#endif > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CAP_GUEST_MEMFD: > > + return !kvm || kvm_arch_has_private_mem(kvm); > > #endif > > default: > > break; > > @@ -5277,6 +5312,18 @@ static long kvm_vm_ioctl(struct file *filp, > > case KVM_GET_STATS_FD: > > r = kvm_vm_ioctl_get_stats_fd(kvm); > > break; > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CREATE_GUEST_MEMFD: { > > + struct kvm_create_guest_memfd guest_memfd; > > Do we need a guard of below? > > r = -EINVAL; > if (!kvm_arch_has_private_mem(kvm)) > goto out; Argh, yeah, that's weird since KVM_CAP_GUEST_MEMFD says "not supported" if the VM doesn't support private memory. Enforcing that would break guest_memfd_test.c though. And having to create a "special" VM just to test basic guest_memfd functionality would be quite annoying. So my vote is to do: case KVM_CAP_GUEST_MEMFD: return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM); There's no harm to KVM if userspace creates a file it can't use, and at some point KVM will hopefully support guest_memfd irrespective of private memory. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.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 E3BBA3A279 for ; Fri, 10 Nov 2023 18:23:01 +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="gzQtL+ol" Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-5b02ed0f886so31980697b3.0 for ; Fri, 10 Nov 2023 10:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699640581; x=1700245381; 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=/u2JG0fndtvz5StB0AokXkOquj7NpP7M8gj3x0QBG2E=; b=gzQtL+olN6w2uF9qh8/Ogohu2Fmonu7sDqK1tx+y3YKwDexVExLPcl5QAz48YwkjX1 Rdz5y7ZjHJbLBZaBx8D/4CMr9+7mkJWBcQVY7koFRnSetMbTDh/64gzRZ5bq9Cf8qSWE ETiE4jMDWM6XZHoMQWXLetibYp7yBUc+Y/0UWRBaxb7LuDxP8eOhxCceaFepoKRfeRrm XcBvjpnK7954nPk9LmRAMuJdSroajhW8TKbq5UfGIEpkixh7tMYuDnogJ128TwR1fdys 4pUR4eI1vJphCCA8w8enCA6PPLXqE9o3eEPz6icGDtStTix2NP9lq9Q1KIfqGA+jN/9V SRkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699640581; x=1700245381; 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=/u2JG0fndtvz5StB0AokXkOquj7NpP7M8gj3x0QBG2E=; b=P1JIpZt8+jxEa7jBeFZDHULfiwFzt3MrTHdROBi5n9YvESyVmFaxaH+zoB58pwepZr 67JgN70qjco5kR5hn1RU8LJ82FVzGvAXLNoQkGXeqm4qbya0HUCYMSR4cf3GkUBvOIOv 2QkApvk48kZz1M6le6T9/WNQfdIMpFgZXRm84yPXiutBlZmgVbL5wzH7HBZ4a7xSfBfR fGM7f5as6suZm5QqwuNcKNLLtHnMKg3JGfN1zdRYlqkwmN62gmAsp3AMp6AAMOIwUQPl ExbQJVMk3KDrvlAslPy7xU+si8kfr/WAMPEpBEXfRpO9qDxX+ZWPxZjnkwtbZqyu2uc7 QF6w== X-Gm-Message-State: AOJu0YyPmsU0IlUdiOi3qZ75nJMkvDN1/FFPJEewiYPqRwGyDMakjzeu juJ13LMdT4FqvN9Abp8FJuZN3Ia8QLU= X-Google-Smtp-Source: AGHT+IFilgu1/Q1EZiEoL3sTFYKCQfnhtgAeMBBAfAGcs6DHfZF6Y3nZ5EepLJy80XYZ0ZRT2keQkzxRdJY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:ef0c:0:b0:5be:ae71:d70a with SMTP id o12-20020a81ef0c000000b005beae71d70amr242444ywm.4.1699640580898; Fri, 10 Nov 2023 10:23:00 -0800 (PST) Date: Fri, 10 Nov 2023 10:22:59 -0800 In-Reply-To: <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20231105163040.14904-1-pbonzini@redhat.com> <20231105163040.14904-16-pbonzini@redhat.com> <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.com> Message-ID: Subject: Re: [PATCH 15/34] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Xiaoyao Li 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, 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 Fri, Nov 10, 2023, Xiaoyao Li wrote: > On 11/6/2023 12:30 AM, Paolo Bonzini wrote: > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index 68a144cb7dbc..a6de526c0426 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@ -589,8 +589,20 @@ struct kvm_memory_slot { > > u32 flags; > > short id; > > u16 as_id; > > + > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + struct { > > + struct file __rcu *file; > > + pgoff_t pgoff; > > + } gmem; > > +#endif > > }; > > +static inline bool kvm_slot_can_be_private(const struct kvm_memory_slot *slot) > > +{ > > + return slot && (slot->flags & KVM_MEM_GUEST_MEMFD); > > +} > > + > > maybe we can move this block and ... > > > > > @@ -2355,6 +2379,30 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > bool kvm_arch_post_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > + > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM) && > > + kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE; > > +} > > +#else > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return false; > > +} > > #endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */ > > this block to Patch 18? It would work, but my vote is to keep them here to minimize the changes to common KVM code in the x86 enabling. It's not a strong preference though. Of course, at this point, fiddling with this sort of thing is probably a bad idea in terms of landing guest_memfd. > > @@ -4844,6 +4875,10 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > case KVM_CAP_MEMORY_ATTRIBUTES: > > return kvm_supported_mem_attributes(kvm); > > +#endif > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CAP_GUEST_MEMFD: > > + return !kvm || kvm_arch_has_private_mem(kvm); > > #endif > > default: > > break; > > @@ -5277,6 +5312,18 @@ static long kvm_vm_ioctl(struct file *filp, > > case KVM_GET_STATS_FD: > > r = kvm_vm_ioctl_get_stats_fd(kvm); > > break; > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CREATE_GUEST_MEMFD: { > > + struct kvm_create_guest_memfd guest_memfd; > > Do we need a guard of below? > > r = -EINVAL; > if (!kvm_arch_has_private_mem(kvm)) > goto out; Argh, yeah, that's weird since KVM_CAP_GUEST_MEMFD says "not supported" if the VM doesn't support private memory. Enforcing that would break guest_memfd_test.c though. And having to create a "special" VM just to test basic guest_memfd functionality would be quite annoying. So my vote is to do: case KVM_CAP_GUEST_MEMFD: return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM); There's no harm to KVM if userspace creates a file it can't use, and at some point KVM will hopefully support guest_memfd irrespective of private memory. 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 6155DC4167D for ; Fri, 10 Nov 2023 18:23:14 +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=ndxdwwxIBzSs+sKpCsH9f3W0Fc4V+s8BYE6RIRb6Xro=; b=gFaZvcpze+vC593bc9n+EDQorO c0pIFrMAUSGlYeIoo8FGF/2WSuuJaAzlwbH55vuY8hGcoKfrkNL7xnHsZ93wH4qRAioEuEnsdwA7a BO92lpzSSoeELqeCe3RVeXgeT5k+Ky0xI000+668JCUXGktOpFHbJ/O1CYF1cbbJTC3yauwkqGH84 B4peO0cE2ZBChuryWVAmMxtWetjQailDyd9I63iTSYB0YrqBgJvOIpH5U68W43XZMh1/5SYwsbxit bb+mby5yxfl02apWHOphNV+qDeUBCiJKLrJ5rafyYp6X7a6oTDxaqMjI7a/4wJPjQuxvvMrlnrxx/ 56S45c2A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r1W9r-009ECA-2W; Fri, 10 Nov 2023 18:23:07 +0000 Received: from mail-yw1-x1149.google.com ([2607:f8b0:4864:20::1149]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r1W9o-009E9w-0T for linux-riscv@lists.infradead.org; Fri, 10 Nov 2023 18:23:06 +0000 Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5b1ff96d5b9so31778477b3.1 for ; Fri, 10 Nov 2023 10:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699640581; x=1700245381; 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=/u2JG0fndtvz5StB0AokXkOquj7NpP7M8gj3x0QBG2E=; b=MUSyrQpV43BGlYXNFS0rbHybNOJp2tO7C5me5bX63NHu22IMa73vdw795LR9LuebSz Zrow+5HKu4AkksSzzJUSh62btuvpYY6WM1thjvjMwrQNZdewJk/Tng0MIzcFGAXDhKyj aEit1g9SaXFJXSKCMmOipOxs1yDCHtm2Pm6tsuENgnTrRE6yg637s4Fe45viCJrxXuyv 0xaTrVfQgPOP2ed5qQsEI/r7PyyKC5J0qYSpvlM4FijzGkJtXwmoSfSUBi4owJLvArSq j1M5Vcc+DtdjU6wvl5A1sOBWq/wFVKNObg/UmPfrnTaX4y94APABFtf3ghChvaPdieJk oVJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699640581; x=1700245381; 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=/u2JG0fndtvz5StB0AokXkOquj7NpP7M8gj3x0QBG2E=; b=GZQCHgXvyVYoMut4HvlQFM1ebOD/VKthmONfEMDxUftM0HxHgfbexYe3NNSM3VVDWL 0VgojuHDEZYRlq0k+wXfYoJG2dtYHrhd0149ndZ5hSw4LWJWBgxKcyRU5oo9y+bzJzb/ 3o6EJsxQucOHq0J21YArqLw5mc2SxrRLRmFsQR/1h64IfdQUSXTvglnSVz5z+iUjB75n 56Ay19oy666JyX5P/r1cRlzWr41ZAx1vhDWYBkjXsubRRaWwS2lyiWjCK7bM7R3UTb1c 3jjPH9bZg9trW++cv2rAupOXBZbBgXsl1BT3SUFF7hKjOehaUSNRzKQboIMd1olBWnaz qTWg== X-Gm-Message-State: AOJu0YyJ3XXWmZsWtE111fltDyqXd/rff4LMZOoVouWTlo86UK1CaoXw DUkenkUqolFc4zsEqg8E39j5OHq0WBk= X-Google-Smtp-Source: AGHT+IFilgu1/Q1EZiEoL3sTFYKCQfnhtgAeMBBAfAGcs6DHfZF6Y3nZ5EepLJy80XYZ0ZRT2keQkzxRdJY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:ef0c:0:b0:5be:ae71:d70a with SMTP id o12-20020a81ef0c000000b005beae71d70amr242444ywm.4.1699640580898; Fri, 10 Nov 2023 10:23:00 -0800 (PST) Date: Fri, 10 Nov 2023 10:22:59 -0800 In-Reply-To: <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.com> Mime-Version: 1.0 References: <20231105163040.14904-1-pbonzini@redhat.com> <20231105163040.14904-16-pbonzini@redhat.com> <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.com> Message-ID: Subject: Re: [PATCH 15/34] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Xiaoyao Li 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, 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-20231110_102304_184751_40EB579E X-CRM114-Status: GOOD ( 19.33 ) 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, Nov 10, 2023, Xiaoyao Li wrote: > On 11/6/2023 12:30 AM, Paolo Bonzini wrote: > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index 68a144cb7dbc..a6de526c0426 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@ -589,8 +589,20 @@ struct kvm_memory_slot { > > u32 flags; > > short id; > > u16 as_id; > > + > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + struct { > > + struct file __rcu *file; > > + pgoff_t pgoff; > > + } gmem; > > +#endif > > }; > > +static inline bool kvm_slot_can_be_private(const struct kvm_memory_slot *slot) > > +{ > > + return slot && (slot->flags & KVM_MEM_GUEST_MEMFD); > > +} > > + > > maybe we can move this block and ... > > > > > @@ -2355,6 +2379,30 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > bool kvm_arch_post_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > + > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM) && > > + kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE; > > +} > > +#else > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return false; > > +} > > #endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */ > > this block to Patch 18? It would work, but my vote is to keep them here to minimize the changes to common KVM code in the x86 enabling. It's not a strong preference though. Of course, at this point, fiddling with this sort of thing is probably a bad idea in terms of landing guest_memfd. > > @@ -4844,6 +4875,10 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > case KVM_CAP_MEMORY_ATTRIBUTES: > > return kvm_supported_mem_attributes(kvm); > > +#endif > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CAP_GUEST_MEMFD: > > + return !kvm || kvm_arch_has_private_mem(kvm); > > #endif > > default: > > break; > > @@ -5277,6 +5312,18 @@ static long kvm_vm_ioctl(struct file *filp, > > case KVM_GET_STATS_FD: > > r = kvm_vm_ioctl_get_stats_fd(kvm); > > break; > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CREATE_GUEST_MEMFD: { > > + struct kvm_create_guest_memfd guest_memfd; > > Do we need a guard of below? > > r = -EINVAL; > if (!kvm_arch_has_private_mem(kvm)) > goto out; Argh, yeah, that's weird since KVM_CAP_GUEST_MEMFD says "not supported" if the VM doesn't support private memory. Enforcing that would break guest_memfd_test.c though. And having to create a "special" VM just to test basic guest_memfd functionality would be quite annoying. So my vote is to do: case KVM_CAP_GUEST_MEMFD: return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM); There's no harm to KVM if userspace creates a file it can't use, and at some point KVM will hopefully support guest_memfd irrespective of private memory. _______________________________________________ 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 B1FB1C4332F for ; Fri, 10 Nov 2023 18:24:02 +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=k1akDEfa; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4SRnJx2lLlz3cVm for ; Sat, 11 Nov 2023 05:24:01 +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=k1akDEfa; 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=3bhvozqykdfkj51ea37ff7c5.3fdc9elogg3-45mc9jkj.fqc12j.fi7@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 4SRnHv2vvBz30fD for ; Sat, 11 Nov 2023 05:23:05 +1100 (AEDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5b02ed0f886so31980747b3.0 for ; Fri, 10 Nov 2023 10:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699640581; x=1700245381; 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=/u2JG0fndtvz5StB0AokXkOquj7NpP7M8gj3x0QBG2E=; b=k1akDEfaYOrqvKjGdfeCoiInVnqlLSoe9ZpTfAyvjtdQVV0RVTfQUCnrCi222J0iUw ie5DdCAQhl+WL01Nj32jh0QyB3VoSE95PIRHuCY9eklKQDqPoEMj5WteRLIA3LvlR0+w yiaKQ5cQtmg7nvOFLgqf0n4Y/QX9aAL0N7FPPdjTCR4bzNFMDr73O44fQlIYR4YS7Xcu qlPFMU8dwUiOjMPuQzK9J2JhIpY0lPXGB9Ma8rpS8nU/daDsBD26HjTK8iJi6ShTp482 TjSmuLlTKIGF2freWcXaf646ZQEGJNmzrjOB396UXSE/FDEBFKM0e3rUnhL9Xjcw9V0Z 1xJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699640581; x=1700245381; 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=/u2JG0fndtvz5StB0AokXkOquj7NpP7M8gj3x0QBG2E=; b=juGpjG0whjO01Y8Cqju48fTrMjvhbeACXOYzpx2bFLRWip/at0YhP7aGQ/MrQgpIyo bXZDJ8rg4lhUX8pHE57/Lx2CiTKi6ThZP6ZmTfpfAJoeWF/ptLmcij6U2ekoOCxo9mAX 6EpUM1N2wxc+rf1CEwiOmRiTqNweZYOeUojAmgaPfiEvIBNUhYSOdzvLrUMNj7SCx2UN nMK9rtp+nrRz0BsjSHmJZpwMYEpO3ky7BKqNc2TjFV/AO+Aka+YFJq2lOlJMhwOJ3Kfy 5xi4k5Ic7jzg1n+uyINpwueMtvpCWS/dwOnrj6f3nwtumDfCZzqDrt8y8DlZ3chjyk7w IQSA== X-Gm-Message-State: AOJu0Yw7xhj/isUDZLps8ieJey4JH56QyiHE7HAEVBu+KYHQF2jgWJ8o AYcJRBrACfYK0mqlE7WB6b/RlPrIPsA= X-Google-Smtp-Source: AGHT+IFilgu1/Q1EZiEoL3sTFYKCQfnhtgAeMBBAfAGcs6DHfZF6Y3nZ5EepLJy80XYZ0ZRT2keQkzxRdJY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:ef0c:0:b0:5be:ae71:d70a with SMTP id o12-20020a81ef0c000000b005beae71d70amr242444ywm.4.1699640580898; Fri, 10 Nov 2023 10:23:00 -0800 (PST) Date: Fri, 10 Nov 2023 10:22:59 -0800 In-Reply-To: <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.com> Mime-Version: 1.0 References: <20231105163040.14904-1-pbonzini@redhat.com> <20231105163040.14904-16-pbonzini@redhat.com> <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.com> Message-ID: Subject: Re: [PATCH 15/34] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Xiaoyao Li 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 , "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 , Liam 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 Fri, Nov 10, 2023, Xiaoyao Li wrote: > On 11/6/2023 12:30 AM, Paolo Bonzini wrote: > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index 68a144cb7dbc..a6de526c0426 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@ -589,8 +589,20 @@ struct kvm_memory_slot { > > u32 flags; > > short id; > > u16 as_id; > > + > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + struct { > > + struct file __rcu *file; > > + pgoff_t pgoff; > > + } gmem; > > +#endif > > }; > > +static inline bool kvm_slot_can_be_private(const struct kvm_memory_slot *slot) > > +{ > > + return slot && (slot->flags & KVM_MEM_GUEST_MEMFD); > > +} > > + > > maybe we can move this block and ... > > > > > @@ -2355,6 +2379,30 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > bool kvm_arch_post_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > + > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM) && > > + kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE; > > +} > > +#else > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return false; > > +} > > #endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */ > > this block to Patch 18? It would work, but my vote is to keep them here to minimize the changes to common KVM code in the x86 enabling. It's not a strong preference though. Of course, at this point, fiddling with this sort of thing is probably a bad idea in terms of landing guest_memfd. > > @@ -4844,6 +4875,10 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > case KVM_CAP_MEMORY_ATTRIBUTES: > > return kvm_supported_mem_attributes(kvm); > > +#endif > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CAP_GUEST_MEMFD: > > + return !kvm || kvm_arch_has_private_mem(kvm); > > #endif > > default: > > break; > > @@ -5277,6 +5312,18 @@ static long kvm_vm_ioctl(struct file *filp, > > case KVM_GET_STATS_FD: > > r = kvm_vm_ioctl_get_stats_fd(kvm); > > break; > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CREATE_GUEST_MEMFD: { > > + struct kvm_create_guest_memfd guest_memfd; > > Do we need a guard of below? > > r = -EINVAL; > if (!kvm_arch_has_private_mem(kvm)) > goto out; Argh, yeah, that's weird since KVM_CAP_GUEST_MEMFD says "not supported" if the VM doesn't support private memory. Enforcing that would break guest_memfd_test.c though. And having to create a "special" VM just to test basic guest_memfd functionality would be quite annoying. So my vote is to do: case KVM_CAP_GUEST_MEMFD: return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM); There's no harm to KVM if userspace creates a file it can't use, and at some point KVM will hopefully support guest_memfd irrespective of private memory. 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 91DFDC4167D for ; Fri, 10 Nov 2023 18:23:33 +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=n5k9K1l/TUFX13o/Y5rO1607deE8K0mQHLieyaBlOs8=; b=VznkBOKo/1ICZBpmxXHy2JEldR 2nKdNmMQIbJvoHbFqKKmWyRdBTETAzjFLnqBEBKX7rfF5dfO1W3N+W0xW23aaQeggr5uzZvOlPPhl 7zRXUX0OPxWIEqd+34QLNU2dFKFS38DJeIdtpAM8j0+6N3DLe3VcnmEBe7b6hLGBOtpAg813+3agZ +p6lEMxVGyiFkvfjfUv89yMUYOGI9rPkUN6ZhBGEB80uCtDEN31sRxDRZZcIIDHYt5q/PJ2FuICe+ Md71nT4QBjp/TWkK8xIdtQj6LKdPtrDn8DHW6cFKo1XJa8gQDrVchj8dNA+cUROUteRGMHIutLRRp HbL0htBg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r1W9r-009EC2-0k; Fri, 10 Nov 2023 18:23:07 +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 1r1W9n-009E9v-3C for linux-arm-kernel@lists.infradead.org; Fri, 10 Nov 2023 18:23:05 +0000 Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5a8ee6a1801so31711027b3.3 for ; Fri, 10 Nov 2023 10:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699640581; x=1700245381; 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=/u2JG0fndtvz5StB0AokXkOquj7NpP7M8gj3x0QBG2E=; b=MUSyrQpV43BGlYXNFS0rbHybNOJp2tO7C5me5bX63NHu22IMa73vdw795LR9LuebSz Zrow+5HKu4AkksSzzJUSh62btuvpYY6WM1thjvjMwrQNZdewJk/Tng0MIzcFGAXDhKyj aEit1g9SaXFJXSKCMmOipOxs1yDCHtm2Pm6tsuENgnTrRE6yg637s4Fe45viCJrxXuyv 0xaTrVfQgPOP2ed5qQsEI/r7PyyKC5J0qYSpvlM4FijzGkJtXwmoSfSUBi4owJLvArSq j1M5Vcc+DtdjU6wvl5A1sOBWq/wFVKNObg/UmPfrnTaX4y94APABFtf3ghChvaPdieJk oVJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699640581; x=1700245381; 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=/u2JG0fndtvz5StB0AokXkOquj7NpP7M8gj3x0QBG2E=; b=uTxuoAJL1tny4SehdisSxvCVvyu63SLm4sr89jYKvrS7NcRQsQvU29HMbfipE9JGVM HWUxcJfVnRoPQtRb2R0Nv/86/CcjrdjlUK/J0Mbm0mDeNVbomoDnRjzQDo+d5AHDFBJh ae6vWQzSu2hBdhZhd28m4ZtdCowNOPoXE7izR6UYlrv0Vv0ZsUQoSwUhwUgXNw1PQN28 Dcp+8Zddx2CeC7thvLlOnoFZQ29yrFFxlz5qIq3ogF3Iu03LipyiUgBuZzSMHn3TbRZf iivayFbQ03Wcspmeh6iVPlH/2JQtreP2B+8MJd2u0Vab4/aw9H0xOY4/LxRu/bdn/hTS g8AQ== X-Gm-Message-State: AOJu0YyvBSAu/PxMEOiwLVExZkT6fxiv9MUDc49pIwYhc0Y197LN6hBB LgzpEiv4O2Vs2cB3sxc0zgbDe81nAoE= X-Google-Smtp-Source: AGHT+IFilgu1/Q1EZiEoL3sTFYKCQfnhtgAeMBBAfAGcs6DHfZF6Y3nZ5EepLJy80XYZ0ZRT2keQkzxRdJY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:ef0c:0:b0:5be:ae71:d70a with SMTP id o12-20020a81ef0c000000b005beae71d70amr242444ywm.4.1699640580898; Fri, 10 Nov 2023 10:23:00 -0800 (PST) Date: Fri, 10 Nov 2023 10:22:59 -0800 In-Reply-To: <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.com> Mime-Version: 1.0 References: <20231105163040.14904-1-pbonzini@redhat.com> <20231105163040.14904-16-pbonzini@redhat.com> <956d8ee3-8b63-4a2d-b0c4-c0d3d74a0f6f@intel.com> Message-ID: Subject: Re: [PATCH 15/34] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Xiaoyao Li 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, 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-20231110_102304_031821_FA08272B X-CRM114-Status: GOOD ( 20.92 ) 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, Nov 10, 2023, Xiaoyao Li wrote: > On 11/6/2023 12:30 AM, Paolo Bonzini wrote: > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > > index 68a144cb7dbc..a6de526c0426 100644 > > --- a/include/linux/kvm_host.h > > +++ b/include/linux/kvm_host.h > > @@ -589,8 +589,20 @@ struct kvm_memory_slot { > > u32 flags; > > short id; > > u16 as_id; > > + > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + struct { > > + struct file __rcu *file; > > + pgoff_t pgoff; > > + } gmem; > > +#endif > > }; > > +static inline bool kvm_slot_can_be_private(const struct kvm_memory_slot *slot) > > +{ > > + return slot && (slot->flags & KVM_MEM_GUEST_MEMFD); > > +} > > + > > maybe we can move this block and ... > > > > > @@ -2355,6 +2379,30 @@ bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > bool kvm_arch_post_set_memory_attributes(struct kvm *kvm, > > struct kvm_gfn_range *range); > > + > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM) && > > + kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE; > > +} > > +#else > > +static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn) > > +{ > > + return false; > > +} > > #endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */ > > this block to Patch 18? It would work, but my vote is to keep them here to minimize the changes to common KVM code in the x86 enabling. It's not a strong preference though. Of course, at this point, fiddling with this sort of thing is probably a bad idea in terms of landing guest_memfd. > > @@ -4844,6 +4875,10 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg) > > #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES > > case KVM_CAP_MEMORY_ATTRIBUTES: > > return kvm_supported_mem_attributes(kvm); > > +#endif > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CAP_GUEST_MEMFD: > > + return !kvm || kvm_arch_has_private_mem(kvm); > > #endif > > default: > > break; > > @@ -5277,6 +5312,18 @@ static long kvm_vm_ioctl(struct file *filp, > > case KVM_GET_STATS_FD: > > r = kvm_vm_ioctl_get_stats_fd(kvm); > > break; > > +#ifdef CONFIG_KVM_PRIVATE_MEM > > + case KVM_CREATE_GUEST_MEMFD: { > > + struct kvm_create_guest_memfd guest_memfd; > > Do we need a guard of below? > > r = -EINVAL; > if (!kvm_arch_has_private_mem(kvm)) > goto out; Argh, yeah, that's weird since KVM_CAP_GUEST_MEMFD says "not supported" if the VM doesn't support private memory. Enforcing that would break guest_memfd_test.c though. And having to create a "special" VM just to test basic guest_memfd functionality would be quite annoying. So my vote is to do: case KVM_CAP_GUEST_MEMFD: return IS_ENABLED(CONFIG_KVM_PRIVATE_MEM); There's no harm to KVM if userspace creates a file it can't use, and at some point KVM will hopefully support guest_memfd irrespective of private memory. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel