From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 08DC35592FD for ; Thu, 15 Oct 2026 17:17:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792084679; cv=none; b=R+guNNtwpg9ao8nsdQ0q0Jk7bSOYPaPtns+4I0oL05hoOgc0J5qAnCdtWZI2tcilxwWSOz/r/bE3dpa7+BhWLvWNGpwnuIUu4/b6oH+7ti5UFQzIZfWgHHS2Y+HZKnT/RrisT0M61fGugMvrApRvKrZIAl7jyZOs+DhBJP6cYZc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792084679; c=relaxed/simple; bh=97nz3x4cCT7jJVkf7khGZ92jWq9O4MzPPIoGZFfCE3Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KZYvphNm1bXHkLI54FxTM3W1gZddzch5U1Jm8LDoi+a4Fg+V0eeP4V2oKzjetpUjkaOGEU5F+yMjghFHqFe+Kn8xvpFyqscxf4Yc9u2iFFFwehUzOwX5M9fDFfTpNBr/sS7gpZ5zgXAqf59ZqexvWazrNzpOybKtACtwNUG4Hoo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=LGHjnZQ2; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LGHjnZQ2" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-486e70f2457so889172f8f.2 for ; Thu, 15 Oct 2026 10:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1792084669; x=1792689469; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=nUb4cagls44kE5et9qrliHAU76p7w/thb7bKXpN7Lxs=; b=LGHjnZQ2i3mxf4ZTcid18hLmSzPCcPavgFPgZXktiYaRW1loWCVGAx9MKQnl/QcRCf ehi71GtHRfcunwNyEobfohUWmkeA9mNpHK4FLA4407u/3wMFSFhlWGMhG5S2neNoRtEJ zbkFGb+xPzgYcG8N/dR2fxLkkuMk7YYGP73vQni7JEphDT8lsWRDGrTYwq7CHBDrCojT GASpge4oiIj0VCC1VtwWK2UYDpvGJzquN+0TjRWAufqxK1f4pkXz2DlI5Y4bHumxbJ/u Vu9hHXOCPX9rWAqEaf2aAporaEoq3Dq13KZi0t2lBQOo7uWkK1mx2b7X/TcgLYg3LcCj I20A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792084669; x=1792689469; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=nUb4cagls44kE5et9qrliHAU76p7w/thb7bKXpN7Lxs=; b=mKthFjfMq/adzmc8cjNWe44KJePgbf6yOALdedK0YcnwWu0ATSttCexi5R7wUPQCml 0Q8f5Krm9Q8Xqh/X+P/pUqzV2/zsSwcKouYgjQcLL5YDzls8cYoKzq+D5jpmXzbNwneD 5/oy4eKTnI3F5vhY8b/p/opQBsa1YRGWiqv3+6gMPgUrv9MT61tc8NmLTKAVeOcdftew 7h4LYF21YtSExRMg1V0TjxZo9MvKlgqITPF+R78DqQFCK8Mlmk7tBTSjq447iUo2/qe7 ZdHXGxLtB55kJ8bJZx0J5xBhZz5GAO2h59DjqTPVJWDLyWsIPTU1/v1GXFAE3q5FVWS/ iCOg== X-Forwarded-Encrypted: i=1; AKwUvBx+ggZ+9/UQxoappcRkuXUf80q0nc0PDc/hkEuhVugz3SUFxgXawd0KHKx4dwRg3SsPlUY=@vger.kernel.org X-Gm-Message-State: AFq9FYJMqRUEsqVzxfzflQ1GaDlSdWYxtuiZuTnumJm7QL//5d2cHcVi AMp8VdL6cfsG0gP5iVAp3Y1Usi9WDRvKSSQ9ALDlhsnkSiacUbBWfceM X-Gm-Gg: AYBFou3JyAWeZb1495aFVnN6tMUkBxo4AOX+AXSJjVkKrnOJ70jSCwYhweBYtifqRWJ JzpCONA00WXuD0NgNFhkz2r0obIcef7axIPURU5gwi3330ReSEi0ykN4Ig8OXhdHiZHPckRtJ3p BOzKkqDg1UC3txvcJvW3XFyuztR+zWD9sIzAcL8zXMQN321Z3twS9RSD6eNErcsZxomnK0HLlHv M45MlsCtc9uVKBvVgJ3uPqYT05pqxF7EHevV8FAh15UrFMncQl78TGKigY0BxX/8tJCHvOgsTWx 8K600QZzwLM+hkE4l4rr26jdqRwGq3hit99G2HyOVdupFRgEAyYmlg7ReNwcowZZrtH3yuwxLrl Q5Rl0XgMfR1WuGgBvn6QlPXhYhQkjxgd8NvJFXqd6DlbuJoZQUGqGXPiwxhLQ+gDomO64I5NfOJ mnSC5LqwjnfYQaQuhc9dndOxmHdDhwlLF2YOpRgrGhO/KPqpA3fkHiY1PvpsHalMI9LCy/4Br7W zYrj3Jbgmw/3gDrQhrI3j1cZU4l+ZwN6lAXQwLQQiC17d0+uXvSFWGpEZHfMUBRH4SumKwzaT1d vx7IxQBjRPAxqev42z+v+v2N0Rtc413Daa8= X-Received: by 2002:a5d:44cd:0:b0:488:89e4:c3af with SMTP id ffacd0b85a97d-48dbaae4869mr30499724f8f.45.1792084668569; Thu, 15 Oct 2026 10:17:48 -0700 (PDT) Received: from dev-dsk-fgriffo-1c-93421965.eu-west-1.amazon.com (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48dfaf1acd7sm1180327f8f.1.2026.10.15.10.17.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2026 10:17:48 -0700 (PDT) From: Fred Griffoul To: Paolo Bonzini , Sean Christopherson , Marc Zyngier , Oliver Upton , Catalin Marinas , Andrew Morton , David Hildenbrand , Alexander Viro , Christian Brauner , Jan Kara , Jason Gunthorpe , Kevin Tian , Joerg Roedel , Will Deacon , Robin Murphy , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Jonathan Corbet , Shuah Khan , Shuah Khan , Ackerley Tng Cc: David Woodhouse , "Aneesh Kumar K . V" , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Steffen Eiden , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [RFC PATCH 0/9] mm: Memory providers for guest_memfd and iommufd Date: Thu, 15 Oct 2026 17:17:46 +0000 Message-ID: <20261015171746.51538-1-griffoul@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: <20260720111259.122911-1-dwmw2@infradead.org> <20261006183235.16576-1-griffoul@gmail.com> <20261014095702.39676-1-griffoul@gmail.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ackerley Tng writes: > To borrow David's words, the part about this that makes me itch is > conversion. We have to support conversions. Even if it doesn't merge in > the first patch series, we have to have line of sight to how conversions > would work. > > Conversion requests originate from the guest and then the host handles > the guest request by making calling an ioctl on guest_memfd. Hopefully > this part doesn't change with alternative provider support. Agreed, and it doesn't change. Conversions still go through guest_memfd. It is the only one that knows which pages are private. > Suppose guest_memfd still gets the conversion request first, in RFCv2, > to reach all the mappings in various page tables, it would have to be > > + [GUEST_MEMFD] -> [KVM], [USERSPACE] > + [GUEST_MEMFD] -> [PROVIDER] -> [IOMMU] > > since guest_memfd must ensure no IOMMU mappings to guest private pages? > There's that extra step through the [PROVIDER]... Right, there is a step through [PROVIDER]. But it can be a step through the mem_provider code in mm, which every provider shares, rather than through each provider driver. Then guest_memfd doesn't need to know who else maps the frames, and providers don't have to get it right one by one. Here is the idea, on top of your in-place conversion. The VMM gives the same provider file to guest_memfd and to iommufd, as in v2. When guest_memfd converts a range to private, it claims the range: int mem_provider_claim(struct mem_provider_attachment *att, loff_t offset, loff_t len); void mem_provider_unclaim(struct mem_provider_attachment *att, loff_t offset, loff_t len); The claim revokes the range for every other consumer of the file. After that, get_page() returns a hole to them. So iommufd unmaps the pages and can't map them again, and nothing changes on the iommufd side. guest_memfd zaps its own mappings, as it does today. Going back to shared is the reverse. guest_memfd returns the frames to the host first, then unclaims the range. The other consumers then map the frames again. So a conversion looks like: [GUEST_MEMFD] -> [KVM], [USERSPACE] [GUEST_MEMFD] -> [PROVIDER] -> [IOMMU] That is your second chain, but the [PROVIDER] step is the common code in mm/mem_provider.c. It does the revokes and hands out the holes. The provider driver itself only gets one callback, and it can refuse a claim. For example, it would refuse if it also lends those frames through another file. Conversions can already fail, so this fits. If a later step fails, guest_memfd just unclaims the range. This also answers your earlier question. The provider doesn't need to know what is shared or private. It only needs to know which ranges are claimed, so that it doesn't move or share them, and only takes them back once the guest has given them up. I haven't implemented this yet. My plan is to rebase on kvm-x86 next, which has your conversion code. Then I'd demo it with a KVM_X86_SW_PROTECTED_VM and the sample provider. A device sees a shared page, loses it when the page becomes private, and sees the same frame again when it goes back to shared. Does that match what you have in mind? > Thanks, I will prototype what I have in mind too to make sure things > work as I think they will :) Thanks, that would really help. The sample provider and the KVM selftest in the series could be a starting point. Thanks, Fred