From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64B941F0E2E; Thu, 26 Feb 2026 00:25:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772065501; cv=none; b=i05qN+MFAyBy61xDDWVFGTF7MRmNCbS0amo1eVnShnDTg82FOrdeCJ8hsHNx7ZJDPfJ6oVY3UIv40D1INAO2lat/x3wa3nwearbFfgOBASfgQKZhd6S2+upKa5NyAiXr83iEOQNW836hvl3D0ApW6CcghinzbLEahd3eIey8NGM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772065501; c=relaxed/simple; bh=b52uu2gH2CgKqF70w9+b2jEYlCH0p2KqXL61mISEp7Q=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=QDThzkyE6Ek+87djMujXYup3um96AwtVnHXk/uUWLKElHxTmTnXOgp/vMtqAO2fi8LQ7DdJBi14L6Ex4ej2VOL471Hk9nucnbdfsEO1K0veAi7pgEvuGb2WH6d08ySNHp7iHlxLs59YRmcD6+IkpLiInSoiyagIqHoHZLbjrxCI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U4m715XQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="U4m715XQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D284EC116D0; Thu, 26 Feb 2026 00:25:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772065501; bh=b52uu2gH2CgKqF70w9+b2jEYlCH0p2KqXL61mISEp7Q=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=U4m715XQwA1fAW3ZZ4WgxiaMzzAojlHtUmPVEzQex1vE6/DOCoWxyAS9EB6y4h7iF OLVK0TV/6C2vK+k5ePvkOxTAw/CIt+Q8UpeAAxqEOKHxP3A7t4d2DwKXtL6imdfqlA 4V8ORT+SSqP/b0p0484nlsyBnpgnm3gyEV/xfJOxNixdSENszEMyNxtjZjCYFs3Zhu LBCC6LiarhgfQUKJcAqfzTco/C3kdrqpt7nteSnmbFxP0m7fssOaDOSNXK/OwmrYRX botdSpWXigio83YadoMfz9Caw79VmYBD2DOkMCFhEPiFKollV0uDlR5BemKk86CPA7 Lycmaj1135p3Q== Date: Wed, 25 Feb 2026 18:24:59 -0600 From: Bjorn Helgaas To: Alexey Kardashevskiy Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-pci@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , Bjorn Helgaas , Dan Williams , Marek Szyprowski , Robin Murphy , Andrew Morton , Catalin Marinas , Michael Ellerman , Mike Rapoport , Tom Lendacky , Ard Biesheuvel , Neeraj Upadhyay , Ashish Kalra , Stefano Garzarella , Melody Wang , Seongman Lee , Joerg Roedel , Nikunj A Dadhania , Michael Roth , Suravee Suthikulpanit , Andi Kleen , Kuppuswamy Sathyanarayanan , Tony Luck , David Woodhouse , Greg Kroah-Hartman , Denis Efremov , Geliang Tang , Piotr Gregor , "Michael S. Tsirkin" , Alex Williamson , Arnd Bergmann , Jesse Barnes , Jacob Pan , Yinghai Lu , Kevin Brodsky , Jonathan Cameron , "Aneesh Kumar K.V (Arm)" , Xu Yilun , Herbert Xu , Kim Phillips , Konrad Rzeszutek Wilk , Stefano Stabellini , Claire Chang , linux-coco@lists.linux.dev, iommu@lists.linux.dev Subject: Re: [PATCH kernel 8/9] RFC: PCI: Avoid needless touching of Command register Message-ID: <20260226002459.GA3795172@bhelgaas> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260225053806.3311234-9-aik@amd.com> On Wed, Feb 25, 2026 at 04:37:51PM +1100, Alexey Kardashevskiy wrote: > Once locked, a TDI's MSE and BME are not allowed to be cleared. Disallowed by hardware, by spec, by convention? Spec reference would be helpful. > Skip INTx test as TEE-capable PCI functions are most likely IOV VFs > anyway and those do not support INTx at all. "Most likely" doesn't sound like a convincing argument for skipping something. > Add a quirk preventing the probing code from disabling MSE when > updating 64bit BAR (which cannot be done atomically). Say more about this please. If there's something special about this device, I'd like to know exactly what that is. > Note that normally this happens too early and likely not really > needed for the device attestation happening long after PCI probing. I don't follow this either. Please make it meaningful for non-TEE/TDI/whatever experts. And mention that context in the subject line. > @@ -1930,6 +1930,11 @@ static int pci_intx_mask_broken(struct pci_dev *dev) > { > u16 orig, toggle, new; > > + if (dev->devcap & PCI_EXP_DEVCAP_TEE) { > + pci_warn_once(dev, "(TIO) Disable check for broken INTX"); > + return 1; s/INTX/INTx/ Why do users need to know this? Why as a warning? What can they do about it? "TIO"?