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 BBAF8C02198 for ; Fri, 14 Feb 2025 15:12:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4AC7D6B0089; Fri, 14 Feb 2025 10:12:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 435626B008A; Fri, 14 Feb 2025 10:12:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AEE76B008C; Fri, 14 Feb 2025 10:12:41 -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 0CDC66B0089 for ; Fri, 14 Feb 2025 10:12:41 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BA31CB070E for ; Fri, 14 Feb 2025 15:12:28 +0000 (UTC) X-FDA: 83118891576.02.993B1CE Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) by imf13.hostedemail.com (Postfix) with ESMTP id B65D220013 for ; Fri, 14 Feb 2025 15:12:26 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iLhsZoAA; spf=pass (imf13.hostedemail.com: domain of 3WV2vZwYKCBYE0w95y2AA270.yA8749GJ-886Hwy6.AD2@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3WV2vZwYKCBYE0w95y2AA270.yA8749GJ-886Hwy6.AD2@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=1739545946; 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=z55zQaimMbt2FvsqKqjvjDqM4izV/gI6a1eQPX+1LEc=; b=1JbWvrV5vPledzgiOJ6QCNazCNCdGg44qFlCISD0qEPxAOZihxKvLqRXh7iDKGIdaX9AEu 8HuvrYW+HyV+8P5AAKCcMsEUmuq+e0Od6JaSR6chZIvU/s4qNwpAJig8rGU7sMwh2GytCA T9ZXjsADMqvXNoO650OJeqhqMIqflVo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739545946; a=rsa-sha256; cv=none; b=VQiD9CGVzM5TcFzXCLIl+FZNspqhgCrsd2YbIitSJijOY/Tn6S0X2Rtm4Epgqh9t7mk07o qNjBu3NHtYJxiiydDEOozjRVlRYsImlhd20SLIa6dj94pSlDxV6KqtqJmXRM0XeHaxOVvu N1roAMSjL1TxVgqHKK2VVzRUuJzpfjo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iLhsZoAA; spf=pass (imf13.hostedemail.com: domain of 3WV2vZwYKCBYE0w95y2AA270.yA8749GJ-886Hwy6.AD2@flex--seanjc.bounces.google.com designates 209.85.214.202 as permitted sender) smtp.mailfrom=3WV2vZwYKCBYE0w95y2AA270.yA8749GJ-886Hwy6.AD2@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-220e7d654acso25597065ad.0 for ; Fri, 14 Feb 2025 07:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739545945; x=1740150745; darn=kvack.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=z55zQaimMbt2FvsqKqjvjDqM4izV/gI6a1eQPX+1LEc=; b=iLhsZoAANr77KOSvtsuXo9rtmWT5/++4gPbUWWvNZC2mcOPUQT1qMTueb+cy5Lih7w v87WV3bBfK5+jQ2lAI2MJxziJIjm4r+Hh5gQcI/ebFbbUrNDnXjkkhMgaEtWSxvHENGV evoFDEC/HwOrRRf7YBW9ridO1jR6FkK/3XIE36dxTiqMW+rTmnmXXf7x5IDxdr0UhdFR inkuj2Dz4lmNLqjd7iOTlphedFAUegPk7K/L+zIOY984895JTiOmTGdHR/1lMrVmS8iq Cr7r6GDAw+0rd+3ZTYQgGxDiZD9fuTi1L9RSIAAvLvxx5tXRsmj/k2qPY15Lz1KuRRM6 5/RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739545945; x=1740150745; 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=z55zQaimMbt2FvsqKqjvjDqM4izV/gI6a1eQPX+1LEc=; b=n8Fkz3OMORpS3f7w421inQUH/Me2meCrWmcscPONQPhRyzG94efwh6vz2XJXRi/myW Dbot1ZghY4DsHo+gH+2Ga9PGC8qa363AVx1risz8DIQzEcuDpIvMEA2kgyxLIW1LUbVF MJAMZQXmY1I0eP/KPVT5YBFY/xqVuEWaENr4zmDW45IrJZSljvOXtjVkPmjmmwJ4HGkb W5hby6YMIq5arSEJ+7qvB2Sgr9ZcYqB62upM1BI0XH3TtfSVaG9ZJm8Jzs1vnTC/X1gZ zVXGp9v/smJaVIOlwxNsy9cZP9EZWgRXnJfeBEAcJgwFJZJPab+NneBYU6KAxvcsRWba aa/Q== X-Forwarded-Encrypted: i=1; AJvYcCW1yi6KTDGBmqsMhDLLCqqPdxeHtTnvGz7hEPd1++VHd0SUYmjniWrLYx9SMY8E5oW3LF5mMKmH+Q==@kvack.org X-Gm-Message-State: AOJu0YyA0wlHIotUTnfakGQXUFAnKuTGik9dFfZ4A0ThF4xvhUn5vUo+ JfZampNTM+EoVti6YpQ/O5DfGaa1z9Krha44ighiG3XtBT7q19q5xRrxL1Uz3jmlA4K6Qr1irgx B+Q== X-Google-Smtp-Source: AGHT+IFcdkXJQ5mq4r5yhxc+LIPkmYG03Xmdm90vC00pltuvE/fBSBVg/9+YzNBK579Y1GYfnIriEnbbDBA= X-Received: from plgb14.prod.google.com ([2002:a17:902:d50e:b0:220:eaf6:fcbf]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:ec92:b0:21f:6ce8:29df with SMTP id d9443c01a7336-220d33a5d29mr124724705ad.3.1739545945448; Fri, 14 Feb 2025 07:12:25 -0800 (PST) Date: Fri, 14 Feb 2025 07:12:24 -0800 In-Reply-To: Mime-Version: 1.0 References: Message-ID: Subject: Re: [PATCH v3 09/11] KVM: arm64: Introduce KVM_VM_TYPE_ARM_SW_PROTECTED machine type From: Sean Christopherson To: Patrick Roy Cc: Fuad Tabba , Quentin Perret , 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="us-ascii" X-Rspam-User: X-Rspamd-Queue-Id: B65D220013 X-Rspamd-Server: rspam07 X-Stat-Signature: zupupxj8wsnk797naxesh9b617amdmr6 X-HE-Tag: 1739545946-79641 X-HE-Meta: U2FsdGVkX1/Yg+poPYqaMd/rOkz+ndtWori6Mv3CqHG/R+Iz8vY7i2huVsSWO0LqHQA+l2ei+m+MXXIcgyVg4qLGEAEHU3xA4kokv8fbQsdLCXmY4m4IIJYLEX1NhBvrHvi3qobV537YMbS99LRkvNvNqJLr2TPO+sKyoL78JVrmDM0n+Y9y8t2Fqomzia8mEaHI6WB47iBZgNCYShgacSfc0DLwVc9WDFEUdVVnzQOcxbkt++H18VFqNwGfIZH582UtIG3yQjSmE/hcdYgJ66fyTCHcMKl+IxDGpuMslWbcAEMJ1dTKsu9695O/oXCoqAnp91mW9SpH6P8IVdnKeTgKMxTb5sjJlOMCjdQiZCCKGJVnE1PTb+CxHYthz8HGrQdvrjSY/9e4JeWt/yUOfITx0tQIibpXyRsTjJs0LeHEdZzpHissDNM1xUA3nPv07RUAdRz6F2A2TrM0gkcrrdTbd3xZ8WSTYSNYSo3U+koyv/Yb0xXHabKZLm0HntSSSUvXEDM/RBWwXeKKMYqYyv//aaxflmX7jJSlmb9DaK12fk3FZyrX3nQdSj8zAi4s0b3SjgwRwwvKY5k4gHU72x/g6foCGtjYHIeRe2+8dSbSg9b6UEMaODzPzoz2iYMaFk3V0PI6vdyjBuE8rJaUsTfrYLaVh0WwHriPkKNDpEZEQXpMk0ZCkIVruEUJr9Zr7u5EYVqP74k3ggJ3YdxEAlutsZRHwakSmD3yQjDCt7uzGC7Vf7ZY52Um7cOsd4ZTsxlFSzVT/h+JHTDZpUtuS7wGnj5l12qIRvFMEhnerrji2WcQsCyQcNiVSZk9TKH/uOzmkdFpORCt2C0eEfthlkMNTCShbvvlt1Uh6sDfDCcJ2aLAhnlcVt4DxB+lEKY5wLwMzGgOzDynntQmiGn6pswrOT85/mP8ZDRexfFjtnbJiVbB2ppJysZtBqrO7xlW6cbV1x9xqjRaZd+utJm TJEIyn45 f7dNYoFRhEBFKmtUh/FEC0SeE79yZS8EQH14O84qqrBxSxKNca2hBo8962v0qB16Bdq9Q/4vYJ4gSznz0Rw/OBtCoSjQika+nJsMN4ECBU8fRxPKVmIBGqxQqzotXhObH3yn1RvWgKWo3No+zAXKFBZ8Jo2GCjvdb6IkQkXuDO5Bjd4IaC0LWcY4NkYViDgDvA5SiMJeS1Mu/XKu8QsVmf5+W+EGFvIQxbvczhGN7pWJcOynEMgkaeLp083JJ/CQhHP+JpGkM7V8WuLMivI/6TQHdHk1gtMkF9+n4SJGDj5+tElmJ+U+V27ZuCuF2G9/ueqQ6/6QJ8caLO07BVaeEA7BPmXjjv4VzZEIwxYkbazopURw/EZHES/MjcxWMid/EYvlYgnyUKp2yGKp8YEbQgqP+X1u7Z0N9ik9DyBHGt3lwcyNTGnNMhLjobLFpO4ICneBj2SvBfFUhr17fui149sB2NVapLkyQ+JYwdimK48GNvHQxNX3aTh5m+/+2wUlBGL+iHW6JG28lU4UzqbMQ4S3z57YZNnVSiKbdQi0oqeTcm5XEkkiqOnEmgV2Hc71EMwYgY2uCTsQTNX2RDtOiFWN/jFM9+4gtUwZKDDAHjDPKJLUFHnfKJmBmEhZNrqlqbPjdbZMTFchkd8KUIqgyegbSwbdObPhxUy4glx/quqggL7hu3CnErQ3A2Ol6o66qdBONTFMD+6vwLcYLHZ7168F5aw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.020923, 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, Feb 14, 2025, Patrick Roy wrote: > On Fri, 2025-02-14 at 13:11 +0000, Fuad Tabba wrote: > > 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? Once guest_memfd can be mmap()'d, no. KVM_X86_SW_PROTECTED_VM was added for testing and development of guest_memfd largely because KVM can't support a "real" VM if KVM can't read/write guest memory through its normal mechanisms. The gap is most apparent on x86, but it holds true for arm64 as well. > >>>> 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. This aligns with what I see happening for x86, except that for non-protected VMs there will be no shared vs. private, because such VMs won't have a concept of private memory.