From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (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 60802364050 for ; Fri, 9 Jan 2026 18:01:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767981718; cv=none; b=umSvSjOiDTgA9E1CrBBCZILqQ5qSqEFvk9PF8p94fsEml6zSov9s08x3OMgntT36u3k4FUp2NJAbTx/Bf7UrpYlNKrFE31laD8TtBSzl0C95kKrG0rkTMSwj7qPpGEXGuEw7O3ON2TZhCZ4NlFAj1s+BR2VRB8yopilvaOpKlLo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767981718; c=relaxed/simple; bh=8vvLiZ0moy0BqifglQ3lLKAx30/FN3AM0NtBADFZGLE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=axntVEAefhft1e1gIFtRBm6gA/DYDqJW7eSRakPZsaLwEoSKC8d4oWmLFD68kKEzP/fkJyoX11fRXTa1C7FMXD4ry2VBfhRkPG/UJQBF4BSBwlo2K8Gp5miyGJRR55xglDtPHATn0wlYqldAGbqryX/Zei1KWi/H69a7MtnfMas= 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=mxsaMoPN; arc=none smtp.client-ip=209.85.222.180 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="mxsaMoPN" Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-8b23b6d9f11so477022185a.3 for ; Fri, 09 Jan 2026 10:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1767981715; x=1768586515; 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=+sMzdp/YVlx1Jnjwe36wn7sNt4Xwl0SeqEmouO33xVA=; b=mxsaMoPNp3raQJvIVyA/ynyWqlnc2YgDtedCXXWemA1CLdcJ86UmwQxsrAvy0Ps4y/ OtUFn2O7aYkBYXANK7KYmynhqO8mE2Uy5mTzXHDmTN3R/tuytBeakmsRrZw6GVnc8Ya2 wpUv0B/dede8/3MQ76k5pKqiwYYkOllM245R0d4KnRH8UOEJn9c7hSCxw9/UB7zGnqfi AgZ+xGK9ZNb3P7EV7TZz1NZt22pp4EVSMX0ucyg+cVzJl0YqCotruJYsMNDAsWmdp0Yf yMQAk/nIJcUXW3//nj8f/feJl3hf3AyNvuQKx01kJhrWwW/W/llG30lnDAFdf9AkyWWw mIHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767981715; x=1768586515; 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=+sMzdp/YVlx1Jnjwe36wn7sNt4Xwl0SeqEmouO33xVA=; b=OrVgeTK4Uo0kmkEy4jAI/cZ+u7JY2nDJ0bIqcd5lYbrtsdwnTEkKBj/GL+w6akCXjG 02Us84W8fUahzAJyqKF6wC5YY9yDlmRhOSEazgYnqlbsbRTNrLWahsXttW1E+wLPx70b FmaSEiSUdMDRaxDIa+HlJw7HxW4aHQF0bFuA0C+y9CgvVk1rgnYoEWRo4TCidfUdhQzf QnIymW/vubudb8cfowlVCNGcgRcyYTsvIJuem+bfjJn0T5H5/J8NE8bR2+DFL2HuUSCk QJVIPKXExr0XR6b1d9FPIA2EWzJkn5tBFs21eUFy7iGOqOm7Mlaa6yQyqsH7xJffW8/Q RtZg== X-Forwarded-Encrypted: i=1; AJvYcCX/0d07Z1OFwkPo2pTdx3+vgZgkb+DeMBCLZ0pbD1/z6o1KO4OXrgbmgIUuzB0AznsSEOr8ys28U3nELsw=@vger.kernel.org X-Gm-Message-State: AOJu0Yzmr989Rqo0ehfFANxWXByab9u/yn2/uhVHXBPAkC4QT2EsyW2+ Tp3pOw0M73JLRE2hvzPd3Jmpawybj3hUtjc7g9A1MTTjYQVlMQ1ux0fZ0cAP9m1owyo= X-Gm-Gg: AY/fxX6OIf9gtB6UlIMdET/qZ+wsMwUAER1xljr1SwDj6sZc3yBjPFPKjTLFQxbR0E0 K9K6UsaX4acl2Afb80CYpBk5/3wB9DujGoqHrF0r5HEzi63EEkOCyPmaUwSdy2+UeqksHnevPLd wollhJKXDthBcxekULgdHqi+J+0bVUJ7vCEIis+YSyhizGsuh/J5JM5lYaEvYDgPAcpmMmGask5 nOv1evDLcaVrlF+ZYyxeseMp1Xbndf+kMvlh8biBonp8KLWBgVdC9JSgB3O4LdqrQ40WsQHPC5G Mcfzrf5cg3cZJjSMUQE2a8xOGMiumRZwomFyfYscgQli30AewJ1yAnCbRpLsXB7V9WQnQFqe0GT cOCFHxAl+bB2Pf3bMnWuNv7BfwdDibov42GsHjwjBM7eWc5LxWzQXWx1rsLLfTAWbn6oAR7CGaY 7PDvA50lT5sNaLQgqjgGjOx/4AgHOiNnAUe794IRLg+74Yt9J7oYnSgenaSEL+tIMGVhw= X-Google-Smtp-Source: AGHT+IFuH4/syXBn2Q87Uqcqto7RR7Nq5kzUWhGBRuJQqzJjaI4hMXkkvlrpm9zyJZejTp3u6kT6ZA== X-Received: by 2002:a05:620a:371d:b0:8b2:d72d:e41b with SMTP id af79cd13be357-8c3893ef752mr1235192985a.44.1767981715100; Fri, 09 Jan 2026 10:01:55 -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 af79cd13be357-8c37f51ceb5sm916868785a.35.2026.01.09.10.01.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 10:01:54 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1veGo5-000000031Wb-3i4c; Fri, 09 Jan 2026 14:01:53 -0400 Date: Fri, 9 Jan 2026 14:01:53 -0400 From: Jason Gunthorpe To: David Matlack Cc: Alex Williamson , Alex Mastro , Shuah Khan , Peter Xu , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH] vfio: selftests: Add vfio_dma_mapping_mmio_test Message-ID: <20260109180153.GI545276@ziepe.ca> References: <20260108141044.GC545276@ziepe.ca> <20260108084514.1d5e3ee3@shazbot.org> <20260108183339.GF545276@ziepe.ca> <20260109003621.GG545276@ziepe.ca> <20260109005440.GH545276@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 Fri, Jan 09, 2026 at 09:04:30AM -0800, David Matlack wrote: > > If you really want to test TYPE1 you need to test what makes it > > unique, which is that you can map any VMA and then unmap any slice of > > it. Including within what should otherwise be a 1G page. > > > > But I doubt anyone cares enough to fix this, so just exclude > > VFIO_TYPE1_IOMMU from this test? > > Ah, ok, thanks for the explanation. So VFIO_TYPE1_IOMMU should always > use 4K mappings regardless of backend (VFIO or iommufd) so that unmap > can work as intended. IDK, I think you should just ignore testing TYPE1v0. The actual real semantics that it had are quite confusing and iommufd provides an emulation that is going to be functionally OK (indeed, functionally more capable) but is not the exactly the same. The old comment here is sort of enlightening: + * vfio-iommu-type1 (v1) - User mappings were coalesced together to + * avoid tracking individual mappings. This means that the granularity + * of the original mapping was lost and the user was allowed to attempt + * to unmap any range. Depending on the contiguousness of physical + * memory and page sizes supported by the IOMMU, arbitrary unmaps may + * or may not have worked. We only guaranteed unmap granularity + * matching the original mapping; even though it was untracked here, + * the original mappings are reflected in IOMMU mappings. This + * resulted in a couple unusual behaviors. First, if a range is not + * able to be unmapped, ex. a set of 4k pages that was mapped as a + * 2M hugepage into the IOMMU, the unmap ioctl returns success but with + * a zero sized unmap. Also, if an unmap request overlaps the first + * address of a hugepage, the IOMMU will unmap the entire hugepage. + * This also returns success and the returned unmap size reflects the + * actual size unmapped. iommufd does not try to do this "returned unmap size reflects the actual size unmapped" part, it always unmaps exactly what was requested, because it disables huge pages. Jason