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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09A24C4332F for ; Fri, 10 Nov 2023 19:01:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344205AbjKJTBt (ORCPT ); Fri, 10 Nov 2023 14:01:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235469AbjKJTBa (ORCPT ); Fri, 10 Nov 2023 14:01:30 -0500 Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DAB059EED for ; Fri, 10 Nov 2023 10:23:02 -0800 (PST) Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-5a7aa161b2fso31755077b3.2 for ; Fri, 10 Nov 2023 10:23:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699640581; x=1700245381; darn=vger.kernel.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=kgceUlkFOWL5vxm8J4T3HW8CRJFhtUvNgQXZKG4NmhXHIykYFzOaH8R9t4BX7h6pcY HnAGZDCjGPnos9hZqCDNV2l+emmhngiroS8qEFh+3weIBlUqS8XO242R4Zqy5ed49D/h NAPXdCh011lwe3rpaMDBRWEQX1l7Z72wrQHpfKPLgk+HfW3rUsb0oX81O+V4HvUFf3+J wa3wUoXgZf34b9iEXEEW9pJ76Rsj7Z1eFHQx5FB+ycxOuz1YOUa3cKpaFeuSRuBEQCyf UU/rQZF+3oHacw25Ju4lyFult928U9vxNrPknXhgKTa4DoZ612/rCj4I5S8HYrEEEt4L cPEQ== 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=lpjWwBfxZKoqgBYTQy+Vb7gknQxwkkepfPbcC6XXtHapQjrQpaLZQfHF7RRhDB1xuP Drk3Lbf1UxLAbUwqqYGYwxQyz9Tyv6k2vRVB2ftQA+k17+zaDyQw+AqZ+5QNDv8BmjyI JbVJzyZYTYmF0GsKHoWJz+tiFEs+izc/Qgrs92A77XRlfXNEYqQpxSLIQoCvD2QTP9ej OY/l4MKKlHMG08DvfH2sljEqdgHbqJdY3fFT8uCFvlzYEzi/Wpd2JW1huxL9WUM95jKy SeAJKVeuPkPYwuycqyByp+f5ZyntwzUnnjK2lr16Q23xhY9WMMN4f3vsH8P/mDskm+rL X0HQ== X-Gm-Message-State: AOJu0YxDSjh5rjdYgRom62OftVka42B0A7vmsxDUft4lMC4BD59Mz2aN IlbzDM4sVadaOU+RI+sSV+h1hA6ZMvQ= 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" Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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.