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 4964CC02198 for ; Fri, 14 Feb 2025 12:37:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2E2D6B0085; Fri, 14 Feb 2025 07:37:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DE996B0088; Fri, 14 Feb 2025 07:37:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87EC96B0089; Fri, 14 Feb 2025 07:37:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6A8246B0085 for ; Fri, 14 Feb 2025 07:37:54 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D42E0C018B for ; Fri, 14 Feb 2025 12:37:53 +0000 (UTC) X-FDA: 83118502026.13.438332D Received: from smtp-fw-52004.amazon.com (smtp-fw-52004.amazon.com [52.119.213.154]) by imf10.hostedemail.com (Postfix) with ESMTP id B993AC0005 for ; Fri, 14 Feb 2025 12:37:51 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=Ngm0pmSN; spf=pass (imf10.hostedemail.com: domain of "prvs=133848397=roypat@amazon.co.uk" designates 52.119.213.154 as permitted sender) smtp.mailfrom="prvs=133848397=roypat@amazon.co.uk"; dmarc=pass (policy=quarantine) header.from=amazon.co.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739536671; a=rsa-sha256; cv=none; b=BAysjuNfzcODrwK1Sg9RKyBjOMl64KsZfZVM1K8OmDX+63TBe3hJHeWCvKLysggqiTKJ3C h/8jL0RMrSvRihAyHXwB78ceZaU743yEx/D7Vy4UfytnyoKhuX+00vlXZz3ZhC72JswxIQ HHjrq8b8jmLl4GudxFZRyGYqT8dglGk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=Ngm0pmSN; spf=pass (imf10.hostedemail.com: domain of "prvs=133848397=roypat@amazon.co.uk" designates 52.119.213.154 as permitted sender) smtp.mailfrom="prvs=133848397=roypat@amazon.co.uk"; dmarc=pass (policy=quarantine) header.from=amazon.co.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739536671; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Tm+osB2yjHRvqWpYOEEHWB+vgVWcduhdO4iqJ02ZEQY=; b=QpGSWizJxvoxxd1NPGDOj6XOZjnkFL4TMk76GOT3wOmTDLadSyv8oCSMnb2e/06fRJGYZ9 wocEEtZ0G0RCFh80oQCTxVy+rPe5Z/84juaCcO6lJwyF9sgMHJ2iWaADt7ujBr6/Pj4y5b xZl+NHbTVWJpUHsrbFG9ibAcEqy73Hg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt; s=amazon201209; t=1739536671; x=1771072671; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Tm+osB2yjHRvqWpYOEEHWB+vgVWcduhdO4iqJ02ZEQY=; b=Ngm0pmSNRqIajibkmh52WquuJJA+u/YirkrEOFuDNTHy4Hy7a9GHnwMG yOf590fOHDJAHK8BIz1hium5GjQ3ynxlcp8PsiYJdoSGbyAleqmQ2GcBI 8HaGYrx6iwctK/6VBAhRPYUMqog4RNj3yDh59opCx/xBMAh8Y76QWwVq1 g=; X-IronPort-AV: E=Sophos;i="6.13,285,1732579200"; d="scan'208";a="271185207" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO smtpout.prod.us-east-1.prod.farcaster.email.amazon.dev) ([10.43.8.2]) by smtp-border-fw-52004.iad7.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2025 12:37:49 +0000 Received: from EX19MTAUEB001.ant.amazon.com [10.0.44.209:56309] by smtpin.naws.us-east-1.prod.farcaster.email.amazon.dev [10.0.84.99:2525] with esmtp (Farcaster) id 9c016af2-9115-47dc-9bad-cfbb085c541c; Fri, 14 Feb 2025 12:37:48 +0000 (UTC) X-Farcaster-Flow-ID: 9c016af2-9115-47dc-9bad-cfbb085c541c Received: from EX19MTAUEB001.ant.amazon.com (10.252.135.108) by EX19MTAUEB001.ant.amazon.com (10.252.135.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.39; Fri, 14 Feb 2025 12:37:48 +0000 Received: from email-imr-corp-prod-iad-1box-1a-6851662a.us-east-1.amazon.com (10.43.8.2) by mail-relay.amazon.com (10.252.135.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.39 via Frontend Transport; Fri, 14 Feb 2025 12:37:48 +0000 Received: from [127.0.0.1] (dev-dsk-roypat-1c-dbe2a224.eu-west-1.amazon.com [172.19.88.180]) by email-imr-corp-prod-iad-1box-1a-6851662a.us-east-1.amazon.com (Postfix) with ESMTPS id 1720A40627; Fri, 14 Feb 2025 12:37:40 +0000 (UTC) Message-ID: Date: Fri, 14 Feb 2025 12:37:40 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 09/11] KVM: arm64: Introduce KVM_VM_TYPE_ARM_SW_PROTECTED machine type To: Fuad Tabba , Quentin Perret , CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <20250211121128.703390-1-tabba@google.com> <20250211121128.703390-10-tabba@google.com> From: Patrick Roy Content-Language: en-US Autocrypt: addr=roypat@amazon.co.uk; keydata= xjMEY0UgYhYJKwYBBAHaRw8BAQdA7lj+ADr5b96qBcdINFVJSOg8RGtKthL5x77F2ABMh4PN NVBhdHJpY2sgUm95IChHaXRodWIga2V5IGFtYXpvbikgPHJveXBhdEBhbWF6b24uY28udWs+ wpMEExYKADsWIQQ5DAcjaM+IvmZPLohVg4tqeAbEAgUCY0UgYgIbAwULCQgHAgIiAgYVCgkI CwIEFgIDAQIeBwIXgAAKCRBVg4tqeAbEAmQKAQC1jMl/KT9pQHEdALF7SA1iJ9tpA5ppl1J9 AOIP7Nr9SwD/fvIWkq0QDnq69eK7HqW14CA7AToCF6NBqZ8r7ksi+QLOOARjRSBiEgorBgEE AZdVAQUBAQdAqoMhGmiXJ3DMGeXrlaDA+v/aF/ah7ARbFV4ukHyz+CkDAQgHwngEGBYKACAW IQQ5DAcjaM+IvmZPLohVg4tqeAbEAgUCY0UgYgIbDAAKCRBVg4tqeAbEAtjHAQDkh5jZRIsZ 7JMNkPMSCd5PuSy0/Gdx8LGgsxxPMZwePgEAn5Tnh4fVbf00esnoK588bYQgJBioXtuXhtom 8hlxFQM= In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B993AC0005 X-Stat-Signature: r6br8fnz5z5f8emto58zatps4ju5t4ob X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1739536671-469558 X-HE-Meta: U2FsdGVkX19Ti2PggdhYziakvvwJVl0uXyy14KyQ8lt8dKbQ2GfHQqwyVaH287ClBNAmXuzsHpJTXTeWScwyk/I8UsHfqrdk5BmaA0HvWk0apr9HJrgUvRV8YC89MNT9eaMbiATgXCkcItVfKj5kw9htgydBUWvst+IPxL2wKHFitj8XFDuJ0Ijhn//C9rDH51b8jm3tIclAYk1uVY1ePKrAc2oD/AplwDKVg1dD/udIXl8PT0J92GW0gQJspQbgGJTmOuBa9OCeBLgpVEBDA3JTzHlzQ/CNfeDTUhhIvsq0tdVjzTTbt0em98KkBG+EJR3R0S8ftQkTV1OIJPHLODfQS1adCW11hLzceHaOktE0eQHvZiskoyZnVf3jw+KiCSIXGKRzF4J6Myk7RKodMJUWjcFwFVc8N2CIpwxK9t7GuOZppQIinSWpPPjJPnL07502fu1yBjLcDmW5j0K8yDztW2vbEfNLLlrQTf3B7q7DJwx7ngGCJ9nemZ/J6ByDvqcoSk2orfYWOQfnNAOL/p1XApiZ5C6/dmXhR+osIi1qAmKrbsIvBdykpVtwZBcPEY6YviKMyAQnB1Xj2toh2HQXdHU/T2LmfZ+eUtcvtpiv/qR8D8tEpd4HOszqX21PRduQE8e8SlfvFrD6RW/fMXDlTxwIY7JIUDGNdxSWIEKUfIf3veE+4cM62ARVCyoZuUGqFsONGZK3Y4w9h7tQqbMlpR+oqxddiKARa7PhcCQYjEGae3J9iNfirDVjmQ7DyudAy10PPGyliAT4r9GHS5eQmefq1rNw0J3dWAwn9SBINFRrWfpALwSMk7msOMEeDzs092juxxUnKduT13MT7FHGXbYLzJCULnlSJrtb0SPmQwQQtpnEqm6UVTKdg5EJFk3eSll5ctVh0D5qGrcTxhmMqrQNmvf3ndwqsoMiDS1fTrJT0m/jN5dO/l5IJEGoUO1NK2PXvbuDQCIdzWM IRS2vNZ1 Q3PFHJAHLVFDAn3+p1kUra90y7WCCr+V344w44erdz2QWR2z9tRiTCjfv20ZJ4WTWj/dxpNyoFwZcpqU9Hn8lvTf2tk9nklRfDV516vnkqkOaqNLPb5j+ciKSnQlNidBulS0QJ5K6NOhBik+71C68DeUiWMlKeYujOjVRYfrwfk5aRhCAINKsD8zPSUR05pPQjZK1IUk307M+RY3Xg/f+jK9DiFvIJY9Pz3G7Wd9iCBmygL3Mr5qQ3+Y8ND822EYEkHZmD3IAsy2jGne5wuKBnA0sGc+a8KsbhJ0YDYG5z4a22iXp8+T9Hg7Fy+ig9yTg8rv5bF+7f2NYSKv5XKV8F3gSxn0aVaiIeb1lbx+qtZKRNv979h3EdiPfCWh7YP80hk5wFIbOZMpFBLJ4TXYLzxG1z9l0AvF3JlkRDTlawlTnKETySIKTfwgZSFrz5cCQbyR2AWigUeSTlE4F3exp88Z3Fc1ODheTWGiI05hBUZ2tJkZTBiJAJlNcfDDepHaJzbMePBEnf1dAfmTF+6ldFqkJf2T0LQdspda3artNY2Bg8y+9migToCEBgBeualnkRFIP4+n0Cnz/wc9m67OMadXg5PYuD7IYfYDoABx50+8FDA5wES1qsUQMg3IIK2BDT/jl0954+/1DEQI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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)? 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. Best, Patrick > Cheers, > /fuad > >> Cheers, >> Quentin