linux-kernel - Re: [PATCH v2] i915: Support Intel GPU porting on any non-x86 system.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7bd66c59-7101-4e79-9c45-8c3417a4284f@hogyros.de>
Date: Tue, 25 Nov 2025 22:18:43 +0900
From: Simon Richter <Simon.Richter@...yros.de>
To: zhangzhijie <zhangzhijie@...c.ac.cn>, jani.nikula@...ux.intel.com,
 jeff@...fgeerling.com, wangran@...c.ac.cn, zhangjian@...c.ac.cn,
 daniel@...ll.ch, rodrigo.vivi@...el.com, joonas.lahtinen@...ux.intel.com,
 tursulin@...ulin.net, airlied@...il.com, intel-gfx@...ts.freedesktop.org,
 intel-xe@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, guoyaxing@...c.ac.cn
Subject: Re: [PATCH v2] i915: Support Intel GPU porting on any non-x86 system.

Hi,

On 11/24/25 3:56 PM, zhangzhijie wrote:

 > inb/outb speccial wire not support on other ARCH.
 > Should detect whether arch platform support or not.

These platforms still have inb/outb definitions though that do 
something. https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1824 
has a few cases where this goes wrong.

There are also a few Intel chipsets that also allow MMIO accesses to VGA 
registers. Whether there is an intersection of chipsets that allow it, 
and chipsets where that is useful is another question though.

 >   	vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO);

This function really should check if inb/outb will address pdev after 
the function returns, and return an error if not, then the accesses here 
and in the power well code could be conditional on this, and it would be 
generic.

For this, the vgaarb code would need to check that the bridges on the 
way up have accepted the VGA forwarding bit (i.e. read back after 
writing it), and there probably should be a mechanism for the bridge 
between PCI(e) and the platform bus, so systems with multiple PCI(e) 
domains can also be handled.

E.g. on POWER, there are global variables "isa_io_base" and 
"pci_io_base", and it is assumed that these point to a place that 
generates IO accesses from MMIO, but this assumption is not actually 
verified, and I can pretty much guarantee that it's wrong if the PCIe 
bus in question is not even attached to the first socket.

Just checking that upstream bridges accept the VGA bit while vgaarb 
switches decoding over would solve all of my problems though, because 
the root bridge doesn't, so that would be a quick way of inhibiting 
these accesses. It might work for you too, just try setting the bit 
manually with setpci and check if it sticks.

    Simon