From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (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 23F7333C53A for ; Tue, 3 Mar 2026 12:05:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772539558; cv=none; b=LZH6XMH/zw80ZhjUU1GEV+Z1hvsaEAJJZpbqfwjviDEQTC7pmXsWQG7/xe/qyGEvi1zcagiwWwo6Uqfl/VFJTq3NT0Ni9iwnY7g+Q5ADeRgrK632TeuXDyqRSqx7rZ+sBDkFxF17QNtCHpB8d9jWl0bNjjMs0TpXDDuQxXeKFiA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772539558; c=relaxed/simple; bh=1ePO/IgVt2FReZvhWWYrlsfewEOlrQou7s6BZReWdU8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tufvXd/oKupb06fEnrIzw9pEhMilzCUQz1sMB6lNJvkwWiN+zIWk4Ry3LRWmDeYyrGUXWHOJd7TLdAKyflawYyxOR+tWPeY4GrzTL9Og4HWHhyFW9I4GZ4d4ubyXL4k7Inf2Ig83Amhdu3gpbloosT68UT13DtLkrtGZmKF6ljU= 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=gfWXXTGC; arc=none smtp.client-ip=209.85.222.175 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="gfWXXTGC" Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-8cb420f7500so533745385a.2 for ; Tue, 03 Mar 2026 04:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1772539556; x=1773144356; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=jZ1nSawE4P4OeC8ZH5K/sS7Ya9tFRdTVx7qqpOzi/qg=; b=gfWXXTGCRalv1QhudrDGjeNNeM+1uPUMu1e7sDSNWzv3r/oJBSKivOhp18CvPqs8Gt l8LhcEWr+7ZCbQ+WvG2l/vI6DkSoquID8IJLl/D6sPSy2d3dtGhjRNgCB5Kyfah6xyO0 MGdZkhMbr5gLz6IsO3wT8zxyv1KR3hzwzmt774GD967OrX6klETYwScfbSrWd2AaXm4M reHFV5orilc/Mqsmp9/5g2YZ90oKIXMMvhPlz+8tyo1/uB6lfnDbuezfy/fRpKSko4eE RDiAz4OHRKDXS1DftQAOAB1rnvNP9cwB8LgeDch55bJRV3Ss9/wqR9QZOYBrkeBA6Lwq c+NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772539556; x=1773144356; h=in-reply-to:content-transfer-encoding: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=jZ1nSawE4P4OeC8ZH5K/sS7Ya9tFRdTVx7qqpOzi/qg=; b=lnHBXKRhWE4ARuwV5eWf8/iuu5CU9PwWRuopklvWlUSCrAhH3LokK4GSyISWUNH/HU 9HH33jDvD7vc/zzYl/UjDUonQPOE85735Rhj7myuVoapXqpBlaOyDNorGBP8ZnMy9e45 qky3JJUBNQceAyThZnGB7pzOwdeLu4MCjsC0Y4kwyi2ycg1/VvcByl0LXbP0jMc/8bWk jy9n8fTP5FiClH9HkhFcHOmiV5srGfUtE7i69NGvJ0fkZ6VKGJ2/G38svME7C04p54hY 0V76Nfw+437miuWF4ZaI/eCEVkDTTz2XaBqm3XprVTIYPcT/rNUUZ1Eh3PGOzjFssBvq FJPg== X-Forwarded-Encrypted: i=1; AJvYcCWHZkXWntBteWuSn7YE/14CDH0HYa7Pvv2RfSRO7D5+g5Fq/BDjdge1o+Q3w20ItBxeoV0omVzLs4VLJ4o=@vger.kernel.org X-Gm-Message-State: AOJu0Yys7h+nWoaFO1o9VX7NVDrdhI6HMnE3o79yDLsIjZ7824I49/Tm IOHS3okzUik6TQWRSI2xCFKpA64vBOtwKzliGShv5vV2BRm62+DU1lLtNoqYLuxBDL4= X-Gm-Gg: ATEYQzxjSR2TAkIGw3NJiUcKOupfEE5xVblrmnUoV/m6U5qzhm8EPrTJWUekm9UAmjf chaxr6FVlO5GIN6MOlwcZAv+GNvr1coz+mve6eW9w0E5DSTa2z2gMaJE5QuDOhl6t/fSgOFSFS5 jpP6y1PdEc4NArpoOUFYI6TD5/AQpvH/Y/yTiPHYmQTylTANQKz29L96p4FT4ZsJwHXlAA3uCyj VgcHuIdIX+FFpEdbeeuoQhGNJ88N6iSLwM9RM1lKhI9aiTu90tKFxXgfCvBL9dY7iTV+V1oOzBE n8v1CvpYTNOzVpi7ezfMpp69ZUuLtgOEYl/bN1VYoGsBKiYjMafQ95ZhiNhsYhzsTBfNuxVi6UQ 1wWjbb23tTgAXCaoqGYl1LTSLkPuyVG68Ir2mKBPf8QJzH7sfRyXzfDpBhtfFRFvsifxbUuIb3x A7Rcr0p8KsrFVC5U1iGH1KIVr8bDGZLsR+kHJPxiOkrEzWMK353H5/pogZpvYuInwhzLB3W89RK VNvjUx4 X-Received: by 2002:a05:620a:2847:b0:8c6:e0c5:7b9f with SMTP id af79cd13be357-8cbc8df1e96mr2047829385a.44.1772539555915; Tue, 03 Mar 2026 04:05: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-8cbbf7175c6sm1400668685a.37.2026.03.03.04.05.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 04:05:55 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vxOVe-00000004CT6-1weX; Tue, 03 Mar 2026 08:05:54 -0400 Date: Tue, 3 Mar 2026 08:05:54 -0400 From: Jason Gunthorpe To: Ankit Soni Cc: iommu@lists.linux.dev, vasant.hegde@amd.com, suravee.suthikulpanit@amd.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] iommu/amd: Adhere to IVINFO[VASIZE] for address limits Message-ID: <20260303120554.GC964116@ziepe.ca> References: <20260302235715.GY44359@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Mar 03, 2026 at 11:47:21AM +0000, Ankit Soni wrote: > > > + /* > > > + * IVINFO[VASIZE] encodes the log2 of the maximum virtual address > > > + * processed by the IOMMU. > > > + */ > > > + switch (vasize) { > > > + case 32: > > > + case 40: > > > + case 48: > > > + case 64: > > > + return vasize; > > > + default: > > > + pr_warn_once("IVRS: IVINFO[VASIZE]=0x%x is invalid, defaulting to 64‑bit VA\n", > > > + vasize); > > > + return 64; > > > > Why check and limit it like this? > > > > I’ll replace this with a macro and send that in v3. If you have other suggestions, > I’m happy to incorporate. > > > > - cfg.common.hw_max_vasz_lg2 = > > > - min(64, (amd_iommu_hpt_level - 1) * 9 + 21); > > > + cfg.common.hw_max_vasz_lg2 = amd_iommu_hpt_vasize; > > > > This has no restriction, you can send it whatever size you want. > > > > The intent is for the kernel to respect what the VM advertises in IVINFO. > If we ignore IVINFO[VASIZE] and use a larger limit (i.e. from EFR only), > driver can exceed vasize what the VM allows and break the guest. I mean if FIELD_GET(IOMMU_IVINFO_VASIZE, amd_iommu_ivinfo) is 35 why not just pass it to hw_max_vasz_lg2 and be done with it? What is the point of limiting to only a few values? Jason