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 9CE81C02182 for ; Thu, 23 Jan 2025 15:22:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F18FC6B007B; Thu, 23 Jan 2025 10:22:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EA2886B0083; Thu, 23 Jan 2025 10:22:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1B8E6B0085; Thu, 23 Jan 2025 10:22:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B058A6B007B for ; Thu, 23 Jan 2025 10:22:42 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1E03D811DD for ; Thu, 23 Jan 2025 15:22:42 +0000 (UTC) X-FDA: 83039083764.06.527D5CE Received: from smtp-fw-52005.amazon.com (smtp-fw-52005.amazon.com [52.119.213.156]) by imf03.hostedemail.com (Postfix) with ESMTP id F091B2000E for ; Thu, 23 Jan 2025 15:22:39 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=QOeIJoz6; spf=pass (imf03.hostedemail.com: domain of "prvs=11115c5f1=roypat@amazon.co.uk" designates 52.119.213.156 as permitted sender) smtp.mailfrom="prvs=11115c5f1=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=1737645760; 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=P5aqkjPNbdb3uSgVXaztNFotezbG1xCHVak/q8V4drs=; b=lS05cHdqlAtFV1lltq2OsvAthIH3JrePWVJCV96sl0CqYpZLrFkO8IVhI17oWjNmOE3pmS SEt+qF+Cr/j58voRQ482BBYgWmNeAKwDcRk8xyVZibFVLrKvH1avVcSlgfwZ/wSdAJ7svJ B6KmiyCDSXi/Kz7n5mswH+WclHeg1OM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=QOeIJoz6; spf=pass (imf03.hostedemail.com: domain of "prvs=11115c5f1=roypat@amazon.co.uk" designates 52.119.213.156 as permitted sender) smtp.mailfrom="prvs=11115c5f1=roypat@amazon.co.uk"; dmarc=pass (policy=quarantine) header.from=amazon.co.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737645760; a=rsa-sha256; cv=none; b=LMTM0xMe03gZ4oPEHs601ResuAX3Trl+RHwRXpwJlBC5n9pMLK4v23Ip+ELuj0g91rFugS ijeFx/1DJ0L7xVGsjle2AFK0hzpTioR5lP0UDnWHTuuiR2Up+OLS2N2ns/I6BSlZxVYAnw xStY/60HVCZZ2fYFfDzmiyXiSPl1iNg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt; s=amazon201209; t=1737645760; x=1769181760; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=P5aqkjPNbdb3uSgVXaztNFotezbG1xCHVak/q8V4drs=; b=QOeIJoz6r2BN0Avk9uoTG8MiaGFXTXFt2fYV2fLl1QWNqzqxf/M3LgCY +0Do9gcllPnn6Kjf0+Rz2DPQXVm37zAE4obg9o9llgOxIZRnbPzMUgafp 0r6bdjY8VAUvZGAseHnIzZwHh3Yq/wz1O30EnCx6fqdgVediYMERGJ7h+ w=; X-IronPort-AV: E=Sophos;i="6.13,228,1732579200"; d="scan'208";a="713038934" 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-52005.iad7.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2025 15:22:38 +0000 Received: from EX19MTAUEC002.ant.amazon.com [10.0.44.209:46193] by smtpin.naws.us-east-1.prod.farcaster.email.amazon.dev [10.0.10.122:2525] with esmtp (Farcaster) id 0fc5c529-fe2a-45e1-adbb-da2b507588c3; Thu, 23 Jan 2025 15:22:37 +0000 (UTC) X-Farcaster-Flow-ID: 0fc5c529-fe2a-45e1-adbb-da2b507588c3 Received: from EX19EXOUEC001.ant.amazon.com (10.252.135.173) by EX19MTAUEC002.ant.amazon.com (10.252.135.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.39; Thu, 23 Jan 2025 15:22:36 +0000 Received: from EX19MTAUEC002.ant.amazon.com (10.252.135.253) by EX19EXOUEC001.ant.amazon.com (10.252.135.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.39; Thu, 23 Jan 2025 15:22:36 +0000 Received: from email-imr-corp-prod-pdx-all-2c-475d797d.us-west-2.amazon.com (10.43.8.6) by mail-relay.amazon.com (10.252.135.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.39 via Frontend Transport; Thu, 23 Jan 2025 15:22:35 +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-pdx-all-2c-475d797d.us-west-2.amazon.com (Postfix) with ESMTPS id 7A4D5A1EFD; Thu, 23 Jan 2025 15:22:22 +0000 (UTC) Message-ID: <5b2949bf-ab8b-46d4-9daf-71fe3e20b0c8@amazon.co.uk> Date: Thu, 23 Jan 2025 15:22:21 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 2/9] KVM: guest_memfd: Add guest_memfd support to kvm_(read|/write)_guest_page() To: David Hildenbrand , Fuad Tabba CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <20250122152738.1173160-1-tabba@google.com> <20250122152738.1173160-3-tabba@google.com> <82d8d3a3-6f06-4904-9d94-6f92bba89dbc@redhat.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-Server: rspam05 X-Rspamd-Queue-Id: F091B2000E X-Stat-Signature: nfg6qo81m9ixhtfid4utwdotn511yirh X-Rspam-User: X-HE-Tag: 1737645759-546827 X-HE-Meta: U2FsdGVkX19sTYrxx9wejShSGGmWCSGs/UZXSKpgnOxh8SX1aZTv/vPadqei9aWVyKlnZQBqp8Zc6xGFDZrVsHBxFWHRFu15Hoy3LvgGYH6IvAslqqkblpUFWtuNWvgLYZw6QbJ22kdRbZ2DdhVa4H5SrXGtcuzoH4X1fH5HtkbEUxAr9Q3QOfIMwgnWslq85payxMkVfiec7qdtH6yoYk+BBZPbn7j35+0tqNr/sp2bMV4s2dS4cdhDcLUr4ozeNP1jRdcdfrYUuJwyLm9wWnPM9CrT2ZVzaMLgYizNbXc8oe7l9Cz8YlAf+Me5lfTWZjrAwwV21EpFjt+YyetuxDv8/NOHabjuD8CfuJkstNUi4VQ9LBJ1odjmA/j0NHOUIox2UE413yFKutEY0YO4wN0CxtSFRnsfRLz+b58Sq4sKNz6wcBQDHv8OsqmLdqfD6rIwxStkFJHLuEsVRwel2FEVREV0Ulyhnjou4MJCEJY/l7QeQ7r1Xtja/TwHzOKVex6+PyiM4NtjVv1rQ5jFLG8ZRuWacNzeHHz86zu/aNxCvea8Z5/MUcFH0rIBrEgUMJJjGBbxz8kuKhuZjH5wiJEKQZ2sHb1Sz0PMRy2HYsWfFnhgBQGpg064+ORXPXELvOG3vdgrOs3yQqGr81UuCEDMbV2o/zBCuvOb6Y+f3V8BF28qZ760cPvq45ubsmcQiBv6E0xI1Wz7DzMq/yaLSiuYJSkieD0Bl6yeWR5CHcan64k/cAQ0QrwQQm+1T9wr7arhJxU2ziLwVI1wRyaDIuUL3aKdmoZpIt+1i7KAc2O8gJsSGdXKrLr/g8GOc6MVVHpzI2qu+ELbnhW285psIOOWSo2QzAxBavCm0BweSUgWfb8Ki+xjUgFXn5o7WkxPpLxdMNtA1kfncNh9OLt9sGvDkHBfXAE4agr0OhPZmHmaLHrOfuA+OcqrVHQtlZKCbpUtMABzmFvTNYP4sEg ryeR84G4 DpERrHMB1xVf8z98YYfu+zmKF7zQKTXwLK+xTFTb+CwVFNgvjOwOmN2UCGoL2zD6XpLym21oOp0Q1Kz4Stwajg/vYCH+3pUO+TJexp3btWyNTweEkRNLNtFz3iAPOUzdvIC6F7TZkcEnCsShHFVosOxavOQ7+7SH+yvcMXWwsG/I8ryhiMvQxjUDhAmFxSCODEUNa1IQZFP/PyccgRT/TQQ3C7NuV8wCwucnvxxRS+QTjyfxdW+iYnVPa+7lccCvflHFLk9feWKHSwt7fCpWn5elPHgw+XXvxlZmvjytBK6eu1JooJfTWxBMvgH6KtaZVtrn6j0WxaQC7OUcsfeB7GNxLSaDsRYGqVTz5cMO84OSAUTFT8hBE2ivW7JAo/np1JWx0iEVcb9iLf0W7Lay7znJybNaGXSY8QFYnZLdLlpqyj0fOGhHBLcpf2igZLS5IcxBxWA0RKJXJQnCXW4lD1u0V8RIjjucXvBuSuCRuO8hufJqbfvB9IWR9VsRNC6lartBReqjrjjHZSR3sKEpluGo5Kd8y66z0pVHpdwOJC2oqHMAsI4Nj/p9uy3aPpP8I11A2Bc1zSVVd0rAtkAk761iosQTlxIZtXnsIek69Z1yBbdKG2xC9OYBYhw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000053, 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 Thu, 2025-01-23 at 14:18 +0000, David Hildenbrand wrote: >>>> >>>> That said, we could always have a userspace address dedicated to >>>> mapping shared locations, and use that address when the necessity >>>> arises. Or we could always require that memslots have a userspace >>>> address, even if not used. I don't really have a strong preference. >>> >>> So, the simpler version where user space would simply mmap guest_memfd >>> to provide the address via userspace_addr would at least work for the >>> use case of paravirtualized time? >> >> fwiw, I'm currently prototyping something like this for x86 (although >> not by putting the gmem address into userspace_addr, but by adding a new >> field to memslots, so that memory attributes continue working), based on >> what we talked about at the last guest_memfd sync meeting (the whole >> "how to get MMIO emulation working for non-CoCo VMs in guest_memfd" >> story). > > Yes, I recall that discussion. Can you elaborate why the separate field > is required to keep memory attributes working? (could it be sorted out > differently, by reusing userspace_addr?). The scenario I ran into was that within the same memslots, I wanted some gfns to be backed by guest_memfd, and others by traditional memory, so that KVM can GUP some parts of guest memory even if guest_memfd itself is direct map removed. It actually also has to do with paravirtual time, but on x86. Here, the guest chooses where in guest memory the clock structure is placed via an MSR write (so I can't a priori use a traditional memslot, like we can on ARM). KVM internally wants to GUP the hva that corresponds to the gfn the guest chooses, but if the hva is in a mapping of direct map removed gmem, that won't work. So what I did was just intercept the MSR write in userspace, and clear KVM_MEMORY_ATTRIBUTES_PRIVATE for the gfn. But for this, I need userspace_addr to not point to the guest_memfd hva. Although maybe it'd be possible to instead reconfigure the memslots when intercepting the MSR? Not sure where we stand on KVM_MEM_GUEST_MEMFD memslots though. But also conceptually, doesn't KVM_MEMORY_ATTRIBUTES_PRIVATE kinda loose any meaning if userspace_addr also points towards gmem? E.g. no matter what we set, we'd get gmem mapped into the guest. > -- > Cheers, > > David / dhildenb > Best, Patrick