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 27EDAC02198 for ; Fri, 14 Feb 2025 13:18:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 718E96B0085; Fri, 14 Feb 2025 08:18:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EFE36B008A; Fri, 14 Feb 2025 08:18:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B7056B008C; Fri, 14 Feb 2025 08:18:29 -0500 (EST) 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 3D5FE6B0085 for ; Fri, 14 Feb 2025 08:18:29 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BE074C0293 for ; Fri, 14 Feb 2025 13:18:28 +0000 (UTC) X-FDA: 83118604296.17.E526715 Received: from smtp-fw-52002.amazon.com (smtp-fw-52002.amazon.com [52.119.213.150]) by imf12.hostedemail.com (Postfix) with ESMTP id 9EBE94000E for ; Fri, 14 Feb 2025 13:18:26 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=Lved9sGM; spf=pass (imf12.hostedemail.com: domain of "prvs=133848397=roypat@amazon.co.uk" designates 52.119.213.150 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=1739539106; a=rsa-sha256; cv=none; b=6C6M1KuqcTc/gNVruwG2uN2BoaPJ01N9K9TFBmGjdM359ZiyOS1+4lIANAEJ3GKTVLlIQM IKIGnyMNZxGYTZ7lllAljo7FnnCtR/H+WNTblMyz+DXKjw3t7lrEojgdYQLgSR7ziPwCRe F1hn89mL50b3utg8dpDSCxHoyJjB0J8= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=Lved9sGM; spf=pass (imf12.hostedemail.com: domain of "prvs=133848397=roypat@amazon.co.uk" designates 52.119.213.150 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=1739539106; 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=Qr604Rq0b4EyCMGppcLexMAz3k0+4r6zv7y+lpHBXWY=; b=5Hh9ei5wuNQTacwW5hkOuF2Al5WM0jBc9TSACpsuEg0IkhTrL0ABMkQuKKI5bnLaupshCz /1g195YadtxXyeSLNelStY1qEGgO5FQjfxhhOfULORFL/kc3UwSQd+qpkUJP3UfnFGapqF mUFZeS44kn3HERjIswyiPkTdLoSgQ4k= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt; s=amazon201209; t=1739539106; x=1771075106; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Qr604Rq0b4EyCMGppcLexMAz3k0+4r6zv7y+lpHBXWY=; b=Lved9sGMje3knAQ6iCrJOAPvcUzYpioUJUHJ9qJUoS3DeqMLFqVlCM4i vy0TDUCNdQhZ9YXi17R4lPl3aD+2N6+onhqjTQAzh1GEc0k8lkxaT2ajG u1c3Tm7tm3PMUSoF52UP1oKmrZAi8ofWq7MKpR/iaS13+tr87cljoT0U+ I=; X-IronPort-AV: E=Sophos;i="6.13,286,1732579200"; d="scan'208";a="697136415" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-east-1.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-52002.iad7.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2025 13:18:22 +0000 Received: from EX19MTAUEA001.ant.amazon.com [10.0.44.209:22910] by smtpin.naws.us-east-1.prod.farcaster.email.amazon.dev [10.0.85.207:2525] with esmtp (Farcaster) id c17d667e-c13e-4621-96ad-ed98f8aefd40; Fri, 14 Feb 2025 13:18:21 +0000 (UTC) X-Farcaster-Flow-ID: c17d667e-c13e-4621-96ad-ed98f8aefd40 Received: from EX19MTAUEC001.ant.amazon.com (10.252.135.222) by EX19MTAUEA001.ant.amazon.com (10.252.134.203) 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 13:18:10 +0000 Received: from email-imr-corp-prod-iad-1box-1a-9bbde7a3.us-east-1.amazon.com (10.43.8.6) by mail-relay.amazon.com (10.252.135.200) 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 13:18:10 +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-9bbde7a3.us-east-1.amazon.com (Postfix) with ESMTPS id 71A284221E; Fri, 14 Feb 2025 13:18:04 +0000 (UTC) Message-ID: Date: Fri, 14 Feb 2025 13:18:03 +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 CC: Quentin Perret , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , 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: 9EBE94000E X-Stat-Signature: 1ck4uyjgwq6gwt78yhtc46xe3c7t1ej4 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1739539106-951274 X-HE-Meta: U2FsdGVkX18h4B8Z0yw78ziBtptKmCQCD/JtMYk2M+vPXtriO9LFw3Dh99aLGf2mugcV9npuZiTW0Kt5mFYijoTmH4Thktp+XrVC53kRN4AUyh0So8ismF/F//hUsd5vNkG5QEz0ZkMawxtskvd6s7XxxfQeSCM7LCtMwCD9MaaKUfzcxDEyl3drsPesiiuI3Qoy/naGLODhBLzXnixMoF/6q/l23kORSWKsvUagyNkuLkghc//B8IKRKDZ+tpdF4KluhEyjFpbS388ohvOw0wncfLIUy3TezqkBUb1TheEOIvVLy4VWe4h8AANEGVmSzMkmi7YSq6HIHdnKYPl5cdUJuqYjofeHXSJcBsSgslHHVel42zkWhXda+vY+i5PerbvCUdfrtZabA1HXRVGNbXJccOaZDV75hPRf8ulvN7b76IP0+7FdV/ZGBgxn6/VsqQVTHOwxG/ckIeWsHP0dFkasNxvahTch9vPZC2ySKHJ/bw6/7UvXATVwfeD6O/5CzoLWg+LdUTtMl5EbcT3qDgcpOlaXwFSbYOxzPr5n5ZKxjXc423SWPr4SFdQ1HivBqMGN2rKmcFJ6yEFGnz412I2xG8IBUHbitHbQcp3+AuK7ZRthbstQvbox1qj+jjNZXkmky80s3J54iJH5X4gHbB/UtIB3ZfDqtyHQsyZ5TMP7TOEvnRH/rPrYIlN2mFOJ7azth5AsTi+PYtpFbcDRPixyMjLKoWI0sOwNsuc1qI8FYvDJUOYbCRRWLiOBuGXsufOORMHoo5mzf2y6+HUSmVjxYTXtgUpS40EBd/gzG/D5tjR5ZRWvVVMgEZ3gwaRdcJlVahaqvSfibrqW0SkJYU4vexanAbsWM0jahX/TASkeHNTRw53TOcSQl7G/cdsaCSNWktvvm5IsF+lBS5myTRYRjB4HoW66Z/AL8JKtpmlWQxWMUorahBCYd9FB7CCudLMkXUU1BtVCSmAT5zS E6HEv+eJ q3eujWuSXgGtIVNGQx8QyzoAGNZPkit0YJIV68R4MIlJwWy3tqg8UNDlvDv3bbzhw/x6zFawxUkjujjDZCIPkGhkGdkXpGDH8NaSzamT8QXw5Vhr7gfOu+qi10K67tshk4e8siEHY59DcN35BHmX1nuBeBYDAHbgPgPt0pRXScgA0aB8V50RqOcI1v2JBM9fddBTijQNAh3zibbMyyLNMXuz0gDSvdk/6DSKYmOAgxAoT+ZITvBEJu3cfrEhFVZS6RYAn2r0JRh4qfZ2Mfi4AI1iq8+GzGZ1Xo0o/4Y50qNWyNRzmz37fBcmFne4XDWqYyKNLIbkGQD3jhdmi0ywqrBtbN/H1aWEtaPNK/THJ0fMqzOdp8w6AOIKu7iD+3rbKkMhySSofYpd6RABgnX8AhzsH9F+mfg+osS2ke8U1ivfqdppXN33ly/DYmXbfE2ptmUUmWsmLUqOoXnIJbS6YHfvtJUltiYG5jEd3x1y8ovG1giojOGhQzq0Frnn5O/PhsfycMwxUX5xiMwUZ2/CjDamYIZL6HDhbTNx1LU0J/rfDTtTm+EooumZT4r7gbe3g433UmuUGH0CY3gYvSyKDPmTJWyZbMIzSARH+qR2VOHtSUgs4/W5n1p7i2CwR5IQ6MXgR0jFN513D+pTNHk5i5koL4LSBls9/3EvZ 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: List-Subscribe: List-Unsubscribe: On Fri, 2025-02-14 at 13:11 +0000, Fuad Tabba wrote: > 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. Ahh, right, I keep forgetting that CREATE_GUEST_MEMFD() is a vm ioctl. My bad, sorry! >> 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. That makes sense to me, thanks for the explanation! > Cheers, > /fuad > >> Best, >> Patrick >> >>> Cheers, >>> /fuad >>> >>>> Cheers, >>>> Quentin