From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF17635D5E1 for ; Tue, 3 Feb 2026 18:16:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770142582; cv=none; b=FueEKfGuQ+VKtSa+xt4G+iQ4QClh3U51ikZSye2bGFmKmVoORTBkxwK/WNdBtI6n5U/uT5l9tcAC3xkzNF6NKUjk78+Nj73pZ8nlFm4UzAg3CeJknIDrmB6lFWUZ2fhO1wicdX1bFH2szPLZEDL0MGeMvRBK4FpPKgWpvSu8pAc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770142582; c=relaxed/simple; bh=Qt7o89VltFIBegDzasIbqnP3PJ+WPuTLLON/GuX+fRQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YeGjnKwaXhxlxzIEe+xU/tSWvI/Dm6Ympv/nCAuTUaiPyrf6NzMU6E58YMZB545JzUmy52L3dP3h6UgDERfUbGRsnvcc/beMsuev4m/hGJsynEz/+XI1E1itCV4d4cDeZgEOvZALbtO+5mE9guGl8vUqWnic8iI3qFf8+GxYIVE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=Mniz/5oy; arc=none smtp.client-ip=209.85.219.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="Mniz/5oy" Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-89469143ebcso52667996d6.1 for ; Tue, 03 Feb 2026 10:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1770142580; x=1770747380; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mu1la4UZlbEX7cvXzj/Z/hgnRFrqjHU+qKtYtW0dmkY=; b=Mniz/5oynk/qOI64zPIe8E+PNEyixk4fEB611FX5soFdbulK6R9KmPQtOu4aEAXjcB efjpn/kLP3vsSPGaHohVu6/Rt0K9qXP7QtNggw4Y7iGiQ+lb7Btklx97aDYTLAlUztFI h5yvBEF6xvd6QNj3f/5Rq9dS5pMAQ/wKBPWuMCDaLEXtmpFbJnXArLI2UIvYnmp155Zy 0b+yLcNYyG0uUnOruupOuHumm/8Fat9UIruRUI37sLCEsgtmT6QSkgWJF1h0NEiROxuz 1abL4IMKxz9NUHd0G1V4nEtr6+1cDHCJ7YB1uyGxhcm0aubd+Dk72keMw16xEPt7BDo4 yQIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770142580; x=1770747380; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mu1la4UZlbEX7cvXzj/Z/hgnRFrqjHU+qKtYtW0dmkY=; b=dLa5TkotexZG2su49ccEVOU5F4FFAKO1Q8elomfvmjSGwhHh162dZpCKfbqShW3wE/ xEj7Mr3poYMnrl/WMOzWH8tM8OFDNcNSiMpfjV/MAJn9y8w3FpWdxsN6eNfsQpdP2B+P eoDsPaj7qgdMapxWXaCHLhk08uDRF1NFHMDIHR6ieyOSYaQKtahtGvo1fsptO158fTd0 s2hs/XIdZPdf4mP9j3cJs/Fq1lLuZRvkaukm9WhsFrOe8Xv5/3SPxwxvVKyk9IAr8NC3 9yJepzkISUdKBQsOtt0QkE6Pz7RSbKEVxD6IYwbBEl5s81GljobucQG+pbD/APOuoeFx /1dQ== X-Forwarded-Encrypted: i=1; AJvYcCW5VYAXdLhZt2ulNOdmk6PPkQttWPKqV++uIXXxDqyxjCTUcLtB8gA0TKyuUpDyBtARhBNrv/vVJ+D4q0I=@vger.kernel.org X-Gm-Message-State: AOJu0YwQEGf2blAQ4USuV/Rg8IVxot7Y0J2KjiVf6Fzo1DPsdLOirxTF LgAECc22eGsvXvUap4Jsf00NC9slWSoX+gkwGb6jV+pPO6yyqiPfHG+cg/RHKvcgcqibmgnN2xc RpzMX X-Gm-Gg: AZuq6aJ3XSVXuRsuak/qLCB53ZgdqDZmvVyAX2aFfTR1QvZO8n06EULSA3G7bvEw7yu stUrnRrdAi6c1vU0O7Afnb+mfjSzGc/78r9JeQ8MOHNEA2eMt6YekPbt2ghEb7pZJLwwTRkuaiH sR7wO80vqNyr3X4iU0QpydrJxSQxMWyGppoLjAf0LxrPQXKAsrKPtEfASAvV3IYS/yQd/ITktAS 4G7UNoLNbalCF3VnZyJDJVOAkzj1NkBvSTFRuJa8FT9JGX8alLHSdqcU94JbfZyHwPRZmuWLl0y SFjAy24cd3AmLeLCKDoavVmtAjjeGtOs/F2k/qkLSZ6aKG8DZGX8kS95H1WDIuFCxnmNb40oyMz YkHSNPgF2Kq1w0dxt0cFxKKKPUcAx1mCVkSyf7mUzT9TkqF/Cihdbp0tZ7O49E19+WZ6VPX078t v5/HbtvMjQNT9jdhiChV4jt6BljHhxM3QYLkGp5203ocBGxX7i3a/qizoWHtzSmOBtxxo= X-Received: by 2002:a05:6214:20ab:b0:87c:22f9:dac4 with SMTP id 6a1803df08f44-8952210b4a5mr5192876d6.15.1770142579616; Tue, 03 Feb 2026 10:16:19 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89521c00173sm2728446d6.12.2026.02.03.10.16.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Feb 2026 10:16:18 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vnKwk-0000000Gah4-0kfw; Tue, 03 Feb 2026 14:16:18 -0400 Date: Tue, 3 Feb 2026 14:16:18 -0400 From: Jason Gunthorpe To: Xu Yilun Cc: Sean Christopherson , Ackerley Tng , Alexey Kardashevskiy , cgroups@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, x86@kernel.org, akpm@linux-foundation.org, binbin.wu@linux.intel.com, bp@alien8.de, brauner@kernel.org, chao.p.peng@intel.com, chenhuacai@kernel.org, corbet@lwn.net, dave.hansen@intel.com, dave.hansen@linux.intel.com, david@redhat.com, dmatlack@google.com, erdemaktas@google.com, fan.du@intel.com, fvdl@google.com, haibo1.xu@intel.com, hannes@cmpxchg.org, hch@infradead.org, hpa@zytor.com, hughd@google.com, ira.weiny@intel.com, isaku.yamahata@intel.com, jack@suse.cz, james.morse@arm.com, jarkko@kernel.org, jgowans@amazon.com, jhubbard@nvidia.com, jroedel@suse.de, jthoughton@google.com, jun.miao@intel.com, kai.huang@intel.com, keirf@google.com, kent.overstreet@linux.dev, liam.merwick@oracle.com, maciej.wieczor-retman@intel.com, mail@maciej.szmigiero.name, maobibo@loongson.cn, mathieu.desnoyers@efficios.com, maz@kernel.org, mhiramat@kernel.org, mhocko@kernel.org, mic@digikod.net, michael.roth@amd.com, mingo@redhat.com, mlevitsk@redhat.com, mpe@ellerman.id.au, muchun.song@linux.dev, nikunj@amd.com, nsaenz@amazon.es, oliver.upton@linux.dev, palmer@dabbelt.com, pankaj.gupta@amd.com, paul.walmsley@sifive.com, pbonzini@redhat.com, peterx@redhat.com, pgonda@google.com, prsampat@amd.com, pvorel@suse.cz, qperret@google.com, richard.weiyang@gmail.com, rick.p.edgecombe@intel.com, rientjes@google.com, rostedt@goodmis.org, roypat@amazon.co.uk, rppt@kernel.org, shakeel.butt@linux.dev, shuah@kernel.org, steven.price@arm.com, steven.sistare@oracle.com, suzuki.poulose@arm.com, tabba@google.com, tglx@linutronix.de, thomas.lendacky@amd.com, vannapurve@google.com, vbabka@suse.cz, viro@zeniv.linux.org.uk, vkuznets@redhat.com, wei.w.wang@intel.com, will@kernel.org, willy@infradead.org, wyihan@google.com, xiaoyao.li@intel.com, yan.y.zhao@intel.com, yilun.xu@intel.com, yuzenghui@huawei.com, zhiquan1.li@intel.com Subject: Re: [RFC PATCH v1 05/37] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes Message-ID: <20260203181618.GY2328995@ziepe.ca> References: <071a3c6603809186e914fe5fed939edee4e11988.1760731772.git.ackerleytng@google.com> <07836b1d-d0d8-40f2-8f7b-7805beca31d0@amd.com> <20260129003753.GZ1641016@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Feb 03, 2026 at 05:56:37PM +0800, Xu Yilun wrote: > > +1. For guest_memfd, we initially defined per-VM memory attributes to track > > private vs. shared. But as Ackerley noted, we are in the process of deprecating > > that support, e.g. by making it incompatible with various guest_memfd features, > > in favor of having each guest_memfd instance track the state of a given page. > > > > The original guest_memfd design was that it would _only_ hold private pages, and > > so tracking private vs. shared in guest_memfd didn't make any sense. As we've > > pivoted to in-place conversion, tracking private vs. shared in the guest_memfd > > has basically become mandatory. We could maaaaaybe make it work with per-VM > > attributes, but it would be insanely complex. > > > > For a dmabuf fd, the story is the same as guest_memfd. Unless private vs. shared > > is all or nothing, and can never change, then the only entity that can track that > > info is the owner of the dmabuf. And even if the private vs. shared attributes > > are constant, tracking it external to KVM makes sense, because then the provider > > can simply hardcode %true/%false. > > For CoCo-VM and Tee-IO, I'm wondering if host or KVM has to maintain > the private/shared attribute for "assigned MMIO". I'm not naming them > "host MMIO" cause unlike RAM host never needs to access them, either in > private manner or shared manner. > > Traditionally, host maps these MMIOs only because KVM needs HVA->HPA > mapping to find pfn and setup KVM MMU. This is not actually completely true, the host mapping still ends up being used by KVM if it happens to trap and emulate a MMIO touching instruction. It really shouldn't do this, but there is a whole set of complex machinery in KVM and qemu to handle this case. For example if the MSI-X window is not properly aligned then you have some MMIO that is trapped and must be reflected to real HW. So the sharable parts of the BAR should still end up being mmaped into userspace, I think. Which means we need VFIO to know what they are, and hopefully it is just static based on the TDISP reports.. Jason