From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90004C0015E for ; Wed, 26 Jul 2023 19:28:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E35A56B0071; Wed, 26 Jul 2023 15:28:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE5786B0072; Wed, 26 Jul 2023 15:28:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C86B26B0074; Wed, 26 Jul 2023 15:28:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B9EF96B0071 for ; Wed, 26 Jul 2023 15:28:17 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4CB024029C for ; Wed, 26 Jul 2023 19:28:17 +0000 (UTC) X-FDA: 81054749034.30.37C716B Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) by imf26.hostedemail.com (Postfix) with ESMTP id 7AE9114000D for ; Wed, 26 Jul 2023 19:28:14 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=VVF1b7RU; spf=pass (imf26.hostedemail.com: domain of 3zXPBZAYKCOYaMIVRKOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3zXPBZAYKCOYaMIVRKOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690399694; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JT2UHI+2Np7L7QsdeetNAkLhraffv5kgEdfCjKl11Yk=; b=Wp06+i4OifAYSdTiP9IEbjstMWF0bzpDT7+00h7yWW+5au6aJCY8OmR0JzO36EreELYWiF CDNL0ddnPdBd4pMIMLaRFgl0ggmlVAdQOaLV+TRQ/BKlDyI3WlCP8hX03UqpugV8Xsg5u7 ximkLB5gRcLGQ1CHnadEBvv+hDqob/I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690399694; a=rsa-sha256; cv=none; b=i8TDb1TZCDL3dQWz1H5MX79iF41dFvUMWpjmNlvlfnwgvo+TcDhvl0DfFa/jBeP/AGe/Jy Itlf90iT3hTYTB7STQbzrFfZRqZnEEuajed6y6MtEvpYQhqfmGlILdtPLTpX9eCC54wVzz 0vkU17LQsU5TpB2j6WKbXA1gX0ogQ7c= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=VVF1b7RU; spf=pass (imf26.hostedemail.com: domain of 3zXPBZAYKCOYaMIVRKOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--seanjc.bounces.google.com designates 209.85.214.201 as permitted sender) smtp.mailfrom=3zXPBZAYKCOYaMIVRKOWWOTM.KWUTQVcf-UUSdIKS.WZO@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-1b8a7734734so903495ad.2 for ; Wed, 26 Jul 2023 12:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690399693; x=1691004493; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=JT2UHI+2Np7L7QsdeetNAkLhraffv5kgEdfCjKl11Yk=; b=VVF1b7RUawi3/QYYQt22u1jH5OUH1Tf8XnLnE4b/agwXthOwpe69728aWprc+cBAPp m1NzpejyJPFn+J7cEl/k4Xfw7NV/DNs921DAj4mD25qN63m2UV8rxLRjeMa24TJWqXH7 YevHJEPTBXycw8cNMxRiQayY5davffRodPeaquNPMlG3yhTbW+l2TZNv0KoNxIAjUf1u vx7QnvYOOpb+Nn9iea9EFg+zAfgVPq5/2O4eLtzlraYz5aepPr1S1PEGRUkv/ClpXjx1 oD0KN8QbT88DXT6sIsMyGXbNhhlwFsmmZRUM0BDYakuaZeCUCb/tpsShC/zQA5q7Janp MXpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690399693; x=1691004493; 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=JT2UHI+2Np7L7QsdeetNAkLhraffv5kgEdfCjKl11Yk=; b=kruqUS+M1rSFcFSfq9d7Bfd9CO9mnAIi49sbDPHRTq+Kr4ufNORaPdykkU0FyS1DzF a1unlTvrTmfwIXyAFOGr/aoA/0aTGZgZGGLXc6Nmhoc5RQrtuomBAK3N2mCK/mzu8sn4 qolCWeW6YjdV84YEeH8oEertJqEgXuW5D+hqO42o3FKu64YOkcqeHbbgubN/5723aE22 RSyURycgFinEdpy0xM4AZmOAhOBi6B2ktBujs3s93fweuTx3VeBv8qMDyI9FIef/ZCb+ shcjOqpH2S7uGXp877iYRK9HVuFWzuoxwgq/m+ePzDgm07H67g5TcTtroF5IVFbiOFm3 F+MQ== X-Gm-Message-State: ABy/qLa1hbtUajzlwLPh8qQLzLw1C/2pg/x6yQ0/7dm2fo6o0v96hugI r6EF3B69ntRfHBtACP6AWCjzeLSSKrw= X-Google-Smtp-Source: APBJJlGcmwLcdH6TXOymYc9nTB5UyZup+2YRvQp3iON5gHoKZStwU7nqu5mwxNJ6DvyQEbhf1ifDNjwDMJ4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:ce8b:b0:1b8:2055:fc1f with SMTP id f11-20020a170902ce8b00b001b82055fc1fmr13036plg.2.1690399693010; Wed, 26 Jul 2023 12:28:13 -0700 (PDT) Date: Wed, 26 Jul 2023 12:28:11 -0700 In-Reply-To: <8f7ea958-7caa-a185-10d2-900024aeddf0@quicinc.com> Mime-Version: 1.0 References: <20230718234512.1690985-1-seanjc@google.com> <20230718234512.1690985-13-seanjc@google.com> <8f7ea958-7caa-a185-10d2-900024aeddf0@quicinc.com> Message-ID: Subject: Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Elliot Berman 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 , Yu Zhang , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , Vlastimil Babka , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Content-Type: text/plain; charset="us-ascii" X-Stat-Signature: 83afya46ymwjuf5x8rgtx7smngu495ww X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 7AE9114000D X-Rspam-User: X-HE-Tag: 1690399694-335004 X-HE-Meta: U2FsdGVkX19u6I2ogw2mFG10thI3FRuUwJ5Tu2MI+juct3tGBpiotow1GaPWGDrgZeuiliGSP8zEhAomds8nos+U5+VQuiLXXCpKWbyQZYkYzGGIKHeR4ZMn7gCpvNu+gVh0IZG3wAcI1x7SvlnB7hfTk9xFOGzVcpwZRUjMQJwfyUn7lxeYtb+6czthppdnVxqhhVD5dwgJ1Tph3IbZ/aH0iUm4qxOVOHt6EFWCfxFZC/B9p1irACWsm7f0sna3/ed2QOh4g/O8SAdKk4g/5IxBksIOpdKWRXB82nrwNVYmCcVbdZnAlU28Dd5ppS4RSDeuXlmyB+jpMYHKr65/6IfDz56QMetbmhczm3cyd3PyAs9qtsBhBFoWeOiwqznjtC6lMskNq7hIJbuBlHFzSKbLPotJVu0iR5G7kulye2ZsJHGtqQtUfAfJkc5gF3kW19R3veVlnbQ/CN1/pNlbVr5TNfOJnRqEXtfBs4s2QtR4wKk1agKSTHAAn/LRzKgwXDbVL1zjl6VpnGpIlEDPBnudGY6LfkLZ01DSOQX//ZzjeaDA0of6shaY+B1KgnXNA1QT4KLmaG6qaC5qppkBT5cwYK1OMOaZZY0x/kTRBP89lS7HA1zqUIKcbmHW2I3bdpxShDwaeyzOQg/0KCwPeFj9ycEp6fOQzMtCbs8n5QoEcxGJRiTGqn1VwrPMMIU+z4D8wf35Vm993iNlwbbvOF2CCBuI4Y9GDkaEDKDmX1UqtTF4oiSF2//KHOd9x0zm1EO60PlXf3zAUCqB7ztQU3yadk1mpWY0oJ5WRcb0hXNpwPdz1XwK290/kr/tumj1pHrxp+Jmnvj6yv3/C0UBlWJ8SgVGjHaHBUxnXmLOKYBfIBkcIHkQMvatY1vI4iHT6S7vm6A09J16PNLL+IRnmiyk8E00RKMuG4wrtPtkcVs/tiws42+6e5nE8I6mCN1rdUZVgOFb7n7JGNNVFCH BKxW1+9T zNUsI9/iSLE4lviQVYLLChZh3OALHnlQibanklvG97ExXcApjJrf1tuF1829tjMfj7QZaLDjX+e1KzuDH6Vcc/KlO01fRELglnoPtkSRPgwW39rprDNV5cyY9UUgSqFLsFnmOTHyjF/ga55yeQ8biSEa02IR1hv7GXdwAkAol1mcoxzWeGUTqlvWww/QtWhpvKT0oPePYeptJvvCCVI0OQXYVHw81zIl53f7XCI2MWEiu8QVWYtUKEHPwbJ6OyaOf1kvD2f0rKoXId5ag4Iy2y6EnHMs6Vn38xIQ2goND2jAFDQHl2mAbtHWBZtJ4yjJdmUyasTTnqx/55E3ucQCt4D+JDOeJzI56tT79h7MH45terhrBmxZDrK27kWUwvMVJyoA9LoyFVbsD8N99dDRtxfowdM5ceFnK4iTlUgMc7rXiqX8yNGbs3JPgfjsQa6b04MeeLoW5Nx+hK+2oLAfRQaua84S//IL/xNAWCwX4Ptg4L24enA99i64OgXSylOj/kptHIiPwTeQH+wDKFpqmlD06fNCGFgfeay0Dllskb8dnt0SSSWLrb9+RWTz0lAyyq+qx1kgV8EXZj5BP70xTXkSoOMZL5VYQbhTvK6aG05LjYXJ9767TDC47GbbV4iF9w2oPGdEKrWaln1Q64/CMSAlt4m6ZydhjiKH46eHHaaW91MRbNc27TNyHzWbIsiyQ1jhw+kHONc+aXfw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jul 26, 2023, Elliot Berman wrote: > > > On 7/18/2023 4:44 PM, Sean Christopherson wrote: > > TODO > > > diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h > > index 6325d1d0e90f..15041aa7d9ae 100644 > > --- a/include/uapi/linux/magic.h > > +++ b/include/uapi/linux/magic.h > > @@ -101,5 +101,6 @@ > > #define DMA_BUF_MAGIC 0x444d4142 /* "DMAB" */ > > #define DEVMEM_MAGIC 0x454d444d /* "DMEM" */ > > #define SECRETMEM_MAGIC 0x5345434d /* "SECM" */ > > +#define GUEST_MEMORY_MAGIC 0x474d454d /* "GMEM" */ > > > Should this be: > > #define GUEST_MEMORY_KVM_MAGIC > > or KVM_GUEST_MEMORY_KVM_MAGIC? > > BALLOON_KVM_MAGIC is KVM-specific few lines above. Ah, good point. My preference would be either KVM_GUEST_MEMORY_MAGIC or KVM_GUEST_MEMFD_MAGIC. Though hopefully we don't actually need a dedicated filesystem, I _think_ it's unnecessary if we don't try to support userspace mounts. > --- > > Originally, I was planning to use the generic guest memfd infrastructure to > support Gunyah hypervisor, however I see that's probably not going to be > possible now that the guest memfd implementation is KVM-specific. I think > this is good for both KVM and Gunyah as there will be some Gunyah specifics > and some KVM specifics in each of implementation, as you mentioned in the > previous series. Yeah, that's where my headspace is at too. Sharing the actual uAPI, and even internal APIs to some extent, doesn't save all that much, e.g. wiring up an ioctl() is the easy part. Whereas I strongly suspect each hypervisor use case will want different semantics for the uAPI. > I'll go through series over next week or so and I'll try to find how much > similar Gunyah guest mem fd implementation would be and we can see if it's > better to pull whatever that ends up being into a common implementation? That would be awesome! > We could also agree to have completely divergent fd implementations like we > do for the UAPI. Thoughts? I'd like to avoid _completely_ divergent implementations, e.g. the majority of kvm_gmem_allocate() and __kvm_gmem_create() isn't KVM specific. I think there would be value in sharing the core allocation logic, even if the other details are different. Especially if we fully commit to not supporting migration or swap, and decide to use xarray directly to manage folios instead of bouncing through the filemap APIs. Thanks!