From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.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 38D33393DE2 for ; Thu, 26 Feb 2026 19:07:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772132884; cv=none; b=m0kTT7mbSEGccCqE/wCQf9P9cY6k95K/e38rmKU7Cf3jArSGDRENB077Inv56W7hERhDZ43b7VR0Vlp/ZFddCqUjdLiWPGZ8JIBwc77O+7+Jmi/SdFkMxWkWo7HMnOCiRUbvB9rLBaIhFB3Y+FSZw8xb2RnKZjKzCngrYrZgS5Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772132884; c=relaxed/simple; bh=TCV8SHxQHsXrYuGIcmh++Ac4sy1d4lzsmHPaj831Y4g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=n9A01USbUrPv8AetXC+WpwyT396JpReAvSX/83+n3ICxEG+GX+WQrL7S35cAclGZzyrwZu7ChbdTxcjevTRcG01+B/dBri5pBQr3l3JKr5Qcyqk8vzmQVwCHQP+rDUcpKgoNbXkN0iyaXUeKpf2jVdTfw/N9OhAOhfh6f9P5Z7Q= 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=ENrf3Xmu; arc=none smtp.client-ip=209.85.219.44 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="ENrf3Xmu" Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-899a5cb04f9so18074956d6.2 for ; Thu, 26 Feb 2026 11:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1772132879; x=1772737679; 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=2JiPECMiS4IcPtH3bhy01xeh4Gb/Awq8dGQAxIHV6Bg=; b=ENrf3XmuAu2uaEKbD/sbqd0bBJ1pGgUNkD7Ey1teIkpFnRsaBC7IET+HVov1PcmGdN kqctIkApeAddD2aZNQ6iTizYIuEnmK3gHQQ9qB0PbxtM5LuixAIB2r0WwDfqisLWjcP9 ajAAi8eKj1yAuQUYx/tBOw6bD6ggByBetJ0reWLC7kBcwNVkG9/s9KHVt+JNMpXq+Hyw SPHybM9gc4B0u2hvkB7vs67/TaU8S1BHVHYkWFrp5XAeBctGpEzLyI/5HlCtOCM/qbgJ SpaMF/o7JGUmAmSlfAW/925bVpUzUIUNK5JguzN4JFx8/1Tu/fD2N4P5uNRpnpEAv+G4 Q6ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772132879; x=1772737679; 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=2JiPECMiS4IcPtH3bhy01xeh4Gb/Awq8dGQAxIHV6Bg=; b=b5v5eOyJJI3ug9a1RMYf2oGXEDhK1UPQ01z6QzLnONlCpVEDTfXCRrdF4kzOy8ZfID VXxZObrQlu1e19t2w4+FsQt0Z2K/GKkrGdcuW51wTVwVxz7rlcsY9JN5pmAHRB4jzhJ8 mhAYNhP5MLx2h5X00gFM3aEY6K3ZBbnX7yxn61Hj63fMY5R7f/ndADDJzTB8s9sZz8kg tbbk9Tao7OPckQ9abttKbuk5c+jtvsbOplWsM43FvGG94VkrT4eo95/bHwlpSuIoTGas 8EqlDDP6/hjB3V9JRzHF9S0K2zS2tChqqEW4b/Mtkj0j3K49FreVRHQ/ZdBpWzivb8gQ Y74g== X-Forwarded-Encrypted: i=1; AJvYcCVbANuSy5FKwaBwgoEQPMPfuOc3wKPwOWpOcOOIeNihhKtIn2yyuAy5fNEGhHyNDt2/888MCduy+3y0Lo4=@vger.kernel.org X-Gm-Message-State: AOJu0Yyp72x0Qg/RnPZQGsxfzEQ62SZJaOctdEa+8vncIM83m6/LN/Iu xZFu9Tpti+S5kJ1NJkESLFKepLyEqthapw05C6n5rmDFN6+ZL/RO/nyQy/08BCcAt/0= X-Gm-Gg: ATEYQzxZjpnR6rr1KANhlq1DE7+o1kwMh0Di3H7ip/QJvzN+aMO+MS2lXU2eTR9uMS8 kQqKKVBdAJwnSQiJvEb2ySiJb/B/8WObI68A52PTDIJ8fD8J+1+192kV/ZHX+zmtdPBhWSIxbcS FxUEoU1Zxc6vGN0mBamqD6Sv/s4eqVdZcGEJmMyAL5L6O/vujM65m1FnXR6qgh1lWyfF0N5iGC8 d7j//iaSOXpXy2p/PB9l68wgGSWJKYUSBatireqApoDNyRwCKmXUnui1LTSYHrQk5PLBIQg7Vtb DSZLSf+hukwLsajGAQmVA0E+lF0k2ku0pefV32QKOWKu12OsQHl/FZpJJqXNk24vH+xxHzmpjRg kuzdN691REBD+LyPQJLE0EQafzmsFIkZ7i/kpAAazYk0tcRCnvsMXD8EWNsWt2QyoLUlUdoeI7e Y2zPOZOuQEEBSBCNEA5nOjVHI8Bq+i5rbKbLWDvvRsqpI5no7CVd+PsqgpgFTU2l17C9EDIYgnL MGKwSYy X-Received: by 2002:a05:6214:252f:b0:882:3781:e29d with SMTP id 6a1803df08f44-899d1d7250dmr3034716d6.10.1772132878800; Thu, 26 Feb 2026 11:07:58 -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-899c7376847sm24657116d6.28.2026.02.26.11.07.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 11:07:58 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vvgiL-00000000O8A-1yT1; Thu, 26 Feb 2026 15:07:57 -0400 Date: Thu, 26 Feb 2026 15:07:57 -0400 From: Jason Gunthorpe To: Ackerley Tng Cc: Sean Christopherson , Alexey Kardashevskiy , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Kevin Tian , Joerg Roedel , Will Deacon , Robin Murphy , Paolo Bonzini , Steve Sistare , Nicolin Chen , iommu@lists.linux.dev, linux-coco@lists.linux.dev, Dan Williams , Santosh Shukla , "Pratik R . Sampat" , Fuad Tabba , Xu Yilun , "Aneesh Kumar K . V" , michael.roth@amd.com, vannapurve@google.com Subject: Re: [RFC PATCH kernel] iommufd: Allow mapping from KVM's guest_memfd Message-ID: <20260226190757.GA44359@ziepe.ca> References: <20260225075211.3353194-1-aik@amd.com> 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 Thu, Feb 26, 2026 at 12:19:52AM -0800, Ackerley Tng wrote: > Sean Christopherson writes: > > > On Wed, Feb 25, 2026, Alexey Kardashevskiy wrote: > >> For the new guest_memfd type, no additional reference is taken as > >> pinning is guaranteed by the KVM guest_memfd library. > >> > >> There is no KVM-GMEMFD->IOMMUFD direct notification mechanism as > >> the assumption is that: > >> 1) page stage change events will be handled by VMM which is going > >> to call IOMMUFD to remap pages; > >> 2) shrinking GMEMFD equals to VM memory unplug and VMM is going to > >> handle it. > > > > The VMM is outside of the kernel's effective TCB. Assuming the VMM will always > > do the right thing is a non-starter. > > I think looking up the guest_memfd file from the userspace address > (uptr) is a good start Please no, if we need complicated things like notifiers then it is better to start directly with the struct file interface and get immediately into some guestmemfd API instead of trying to get their from a VMA. A VMA doesn't help in any way and just complicates things. > I didn't think of this before LPC but forcing unmapping during > truncation (aka shrinking guest_memfd) is probably necessary for overall > system stability and correctness, so notifying and having guest_memfd > track where its pages were mapped in the IOMMU is necessary. Whether or > not to unmap during conversions could be a arch-specific thing, but all > architectures would want the memory unmapped if the memory is removed > from guest_memfd ownership. Things like truncate are a bit easier to handle, you do need a protective notifier, but if it detects truncate while an iommufd area still covers the truncated region it can just revoke the whole area. Userspace made a mistake and gets burned but the kernel is safe. We don't need something complicated kernel side to automatically handle removing just the slice of truncated guestmemfd, for example. If guestmemfd is fully pinned and cannot free memory outside of truncate that may be good enough (though somehow I think that is not the case) - and I don't understand what issues Intel has with iommu access. Jason