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 6F302C021A4 for ; Fri, 14 Feb 2025 13:12:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A48386B0088; Fri, 14 Feb 2025 08:12:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D1436B0089; Fri, 14 Feb 2025 08:12:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84BC46B008A; Fri, 14 Feb 2025 08:12:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 636726B0088 for ; Fri, 14 Feb 2025 08:12:37 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E6A60C027A for ; Fri, 14 Feb 2025 13:12:36 +0000 (UTC) X-FDA: 83118589512.15.4F58A79 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf16.hostedemail.com (Postfix) with ESMTP id 0B08C180017 for ; Fri, 14 Feb 2025 13:12:34 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=m9vRC7aN; spf=pass (imf16.hostedemail.com: domain of tabba@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=tabba@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=1739538755; 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=zNi5WLr0Xv0TwHaaZJqiogAW1THAfheVtXEohY4nxzo=; b=GY60Pdi7GsGPiUNohKkNW3w1B+vXn1i1zPJutfhr5ycRCz0uwuES2rUWLEKXFZEOohGujW hBq2c0nV2V0aVmDYiv0S+AMrPZPn28OccTELDTvBr6L9TF2BGDpiV7agnUjh6vUGQ0mF1u aglFTlNo9Cjrp6owIS9TDsO7+8tObEM= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=m9vRC7aN; spf=pass (imf16.hostedemail.com: domain of tabba@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739538755; a=rsa-sha256; cv=none; b=WMs0Soeje8jwcxwND6lWfzWrYYq62Gob64qg4/FapTOMvgclccvbH3yGBAsEre/sT/3g/c HkegFiudYEc3Ug11kvcIDf+uAcQWgrOfvJR7zNOkhRezuIuDrDNmJP74iGRWkrJ4qcjQve zz1VrNrNHi3Lo/LryxFB4jfcPzB/jYw= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-471c9947bb5so214011cf.1 for ; Fri, 14 Feb 2025 05:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739538754; x=1740143554; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zNi5WLr0Xv0TwHaaZJqiogAW1THAfheVtXEohY4nxzo=; b=m9vRC7aNHLpMZPxzXOY+KUQONfoOsaiLvDh1iA+4pXrSd76pvF18l8FBgCZ1imoY9o H5cTpN8CK2RoFjLlEjVX0UFD2w9HHxSlayOgGuQDis+kLG5wn8Z9LGl7iISBvCuAydt8 G91MfTOHaGxlvPi/HdBAbs8Bih6ID1RUL5TyMVnQ6BG9UkRl4QxZdeV72pyCTsNITjaP Pt5Vs8T8MAcgw1eaHLXeVC4u9meh7VyyzI1a/L5Sd67JSSV1KvQu+8uKX78xl1qGB5YL 72e2DiNpP8oKVXOrzD+E0FzibLduh6UinnKLPx6jL3ICGIvCDLn5m6n9PvToWEN1Mnga X1eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739538754; x=1740143554; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zNi5WLr0Xv0TwHaaZJqiogAW1THAfheVtXEohY4nxzo=; b=BHkKJntNzPm2TSkqsp3owGomel+gPrp60kcEA6wUpLqhr44HUn0912tPTYCOAEIL7w j3mvP11q9U+0EGyNUS4uPz50jfR6LNhBcFTcpbh3XwaDthtL3I10EhftaI54L+hlZkS0 BgQTSN0qey8OXcWpaq1NdUyMoiJ2vVCiCQBuufPMDAzK7OIlkEwD1n2ttv6LZJLCRKFu O6sYAbg9pfEpzjjm72W7pno818Dp4/DgiuzUD1L75iKIl6wKbV4seBAntKZVhIHksqhy 6CcVNna44Tj/Xlz+ggcEpCt41c78Sz/7AgKgEXrY1t7kbbS1tDhEzN+wuU2eLY2ne86y mi4g== X-Forwarded-Encrypted: i=1; AJvYcCWo4gZT60QpOztg9ycRSHqVEesSuyJJB6+fz29GP2lZ88m7jN30mrYgnkhxP3ijoaGFG6eGojhNng==@kvack.org X-Gm-Message-State: AOJu0Yw4/NhnamY9zGLzE5MKLbQoX2rd0CCpXDo6vNjg7RmRDLmtsDo9 EO5NPMLdsxt513iG6C7ER4vRuDSw5ipktW/SlE2N+zJgGW7valMwFaOg9AGIaYscXcE/Ol3lb0J +h9MnuBLbLtYO9G09Lri5VjK14GmoIHFT+jCz X-Gm-Gg: ASbGncvSXrP/lNeOWypDU2lpeJX1duMIctgLU8uGmrcUBsTQ/kgrZHVNLJgT7dWMMoS IYLC7qTYqw+9udCDz0mUaPFui4dqSaeCBF2MijkpqWzqXXj0F5tPPqLnHoVS48lMLMenm304= X-Google-Smtp-Source: AGHT+IHfVH3XaWPCkKWV6hxZjYre5tjBmvsTWSU9Jq1gOifZbOjP1USFXc0eACKKDkgOPq5Fn5G8l9QQjOM1vmE8scQ= X-Received: by 2002:a05:622a:1812:b0:471:812b:508 with SMTP id d75a77b69052e-471ce8ef5f7mr3094321cf.14.1739538753745; Fri, 14 Feb 2025 05:12:33 -0800 (PST) MIME-Version: 1.0 References: <20250211121128.703390-1-tabba@google.com> <20250211121128.703390-10-tabba@google.com> In-Reply-To: From: Fuad Tabba Date: Fri, 14 Feb 2025 13:11:56 +0000 X-Gm-Features: AWEUYZkNr2Uul6_iPp94OYAFbo8pAAh3UwwAo4NKDmUwU_-sBj6dQOexcTIaJvw Message-ID: Subject: Re: [PATCH v3 09/11] KVM: arm64: Introduce KVM_VM_TYPE_ARM_SW_PROTECTED machine type To: Patrick Roy Cc: Quentin Perret , seanjc@google.com, kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, yu.c.zhang@linux.intel.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, vannapurve@google.com, ackerleytng@google.com, mail@maciej.szmigiero.name, david@redhat.com, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, keirf@google.com, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, jthoughton@google.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 0B08C180017 X-Stat-Signature: xhu1yhre7f5tamupbwjmi9jyf46o451x X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1739538754-282876 X-HE-Meta: U2FsdGVkX18E4JEg9A9pB+T/MWCpWh09mqlFwLKulW7yofjqIi8UvTgwwz0mq35BGNR9IzfYIZvGl9HDUC6+uAmYqNVw6DtqHC3taafm+5gG9mhtJGgFnegIXjs0iLaFvi9htiehNzp88ipTt5GZktshJPBXwN34LBPNepLoaCwy7w4ATidkblV8v1Qoy8C0XkvjrBiMWbSuKyRWjm+YL8zAWIPfgNAOFYOEbHG4CUUmVWLoZVTXnaBtYVBFtH9c6wgCNMFuQVvO2Btt9Dx8KUQ7095gOChzhtLxdJjwxr7mOa+yQxLv4UH8IJgOWVOcL/dQ+CbstRHKEvG58BHoesdHURb5wDNUGdQjG5Flv9j6/5/dJs2NwU+3xlKrs1XGRW27JwsaR79ecpAB7NdapeYWzfX9y9uALQczNPTOHgOEjWgFifhTjB3d2byRIetNcAQdhGlX60woCV9kwO94MzwKnIRG2OYkpf+QKN5p22uSern4JMVTCCn0c2wcFKvpKmw5PA8Js/8QBod2DicRpsVBQIx91dHLLj+XqR84A5W+97vdoiDk8T5q5Z7+oJZopN4HKnn9XF0YycPtWaFHkQNrOaKKHvR4KZJWiNgrrla1YxGPJ+sx6fzWTxPyWn5m0xSGGUQf0/9Vc7Br04GAWaXwks8K64CxIWym07xfKFljUfBQZiaTS4jIAio89qOgoRGF5X2oGXGwtraeZJmOROLDpYmEJeu+bq5AE/Sk4SjYN8GRW3ZyhNwL26xOu0qOk5Fo8T6bZJpQMUwIt+ZKsV3J+QqRCpmJFUgiMzMSReuNz12juQSzeb0EieP2PqSZrS9SiQw/ZVZU5zUamjmGhUlcDi6EHpximnWzvpp1mBJfVoiHORv6dLbTVlcTaaKyJQbpUcOKN12PUQI3TpoxBmhYg9E1214Dc8cwIcE8kZ0IgH3mWFUMMJNi+REdGe1Ch9y2en9ixw5X/O5WmCt vOPpNT1m WsEkXgISmgvt4dQn9RVDjhrqMfSXadNK/mu4BEOmeR5nlUQ3sYBArb1Q/qUbe/Rs6mrOdgpgrUPHS0mtEofEqBgzRQhAWG2JOzPatPS09UPs5Q4Fkl9dvOKmXVSi48pmEQX155JIuV+ECpm31rODrGlixGsK2pakZ0GPhWjMAhd3hiN5WjwK4stxAbCOCnqLBuSrR2ySwdXcLGVF4CeX24GjbXARR7eTYTgCA9uvFCXpnYu9DpsU5Y6b594qbE4HC4RKGbdUtGoEv2iNAHV4mQ/JCSQsBvwHMpS31YJ5y+Kq2B2vnJg41O2XovqFWe/UhggKBn+/2fG4IEA8I2exV45VWKx4r1YBtGd2qKMfFsQy1jnk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000489, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Patrick, On Fri, 14 Feb 2025 at 12:37, Patrick Roy wrote: > > > > On Fri, 2025-02-14 at 11:33 +0000, Fuad Tabba wrote: > > Hi Quentin, > > > > On Fri, 14 Feb 2025 at 11:13, Quentin Perret wrote: > >> > >> On Tuesday 11 Feb 2025 at 17:09:20 (+0000), Quentin Perret wrote: > >>> Hi Patrick, > >>> > >>> On Tuesday 11 Feb 2025 at 16:32:31 (+0000), Patrick Roy wrote: > >>>> I was hoping that SW_PROTECTED_VM will be the VM type that something > >>>> like Firecracker could use, e.g. an interface to guest_memfd specifically > >>>> _without_ pKVM, as Fuad was saying. > >>> > >>> I had, probably incorrectly, assumed that we'd eventually want to allow > >>> gmem for all VMs, including traditional KVM VMs that don't have anything > >>> special. Perhaps the gmem support could be exposed via a KVM_CAP in this > >>> case? > >>> > >>> Anyway, no objection to the proposed approach in this patch assuming we > >>> will eventually have HW_PROTECTED_VM for pKVM VMs, and that _that_ can be > >>> bit 31 :). > >> > >> Thinking about this a bit deeper, I am still wondering what this new > >> SW_PROTECTED VM type is buying us? Given that SW_PROTECTED VMs accept > >> both guest-memfd backed memslots and traditional HVA-backed memslots, we > >> could just make normal KVM guests accept guest-memfd memslots and get > >> the same thing? Is there any reason not to do that instead? Even though > >> SW_PROTECTED VMs are documented as 'unstable', the reality is this is > >> UAPI and you can bet it will end up being relied upon, so I would prefer > >> to have a solid reason for introducing this new VM type. > > > > The more I think about it, I agree with you. I think that reasonable > > behavior (for kvm/arm64) would be to allow using guest_memfd with all > > VM types. If the VM type is a non-protected type, then its memory is > > considered shared by default and is mappable --- as long as the > > kconfig option is enabled. If VM is protected then the memory is not > > shared by default. > > > > What do you think Patrick? Do you need an explicit VM type? > > Mhh, no, if "normal" VMs support guest_memfd, then that works too. I > suggested the VM type because that's how x86 works > (KVM_X86_SW_PROTECTED_VM), but never actually stopped to think about > whether it makes sense for ARM. Maybe Sean knows something we're missing? > > I wonder whether having the "default sharedness" depend on the vm type > works out though - whether a range of gmem is shared or private is a > property of the guest_memfd instance, not the VM it's attached to, so I > guess the default behavior needs to be based solely on the guest_memfd > as well (and then if someone tries to attach a gmem to a VM whose desire > of protection doesnt match the guest_memfd's configuration, that > operation would fail)? Each guest_memfd is associated with a KVM instance. Although it could migrate, it would be weird for a guest_memfd instance to migrate between different types of VM, or at least, migrate between VMs that have different confidentiality requirements. > Tangentially related, does KVM_GMEM_SHARED to you mean "guest_memfd also > supports shared sections", or "guest_memfd does not support private > memory anymore"? (the difference being that in the former, then > KVM_GMEM_SHARED would later get the ability to convert ranges private, > and the EOPNOSUPP is just a transient state until conversion support is > merged) - doesnt matter for my usecase, but I got curious as some other > threads implied the second option to me and I ended up wondering why. My thinking (and implementation in the other patch series) is that KVM_GMEM_SHARED (back then called KVM_GMEM_MAPPABLE) allows sharing in place/mapping, without adding restrictions. Cheers, /fuad > Best, > Patrick > > > Cheers, > > /fuad > > > >> Cheers, > >> Quentin