On Wed, 16 Apr 2025 23:45:08 +0800 Tomita Moeko <tomitamo...@gmail.com> wrote:
> On 4/16/25 03:04, Alex Williamson wrote: > > On Wed, 16 Apr 2025 01:36:15 +0800 > > Tomita Moeko <tomitamo...@gmail.com> wrote: > >> > >> The generation register also exists on discrete GPUs. In the new xe > >> driver [1], the Battlemage discrete GPU shares the same logic reading > >> GMD_ID_DISPLAY register. The driver itself uses is_dgfx bit mapped to > >> device id. In QEMU, we need to know whether the device is a supported > >> IGD device first before applying the IGD-specific quirk, especially > >> for legacy mode. > >> > >> The most feasible way is to check if kernel exposes VFIO_REGION_SUBTYPE_ > >> INTEL_IGD_OPREGION on that device I think, as only IGD has OpRegion. > >> > >> i915 driver [2] and Arrow Lake datasheet [3] shows that Intel has > >> removed the BDSM register by making the DSM range part of BAR2 since > >> Meteor Lake and onwards. QEMU only need to quirk on the register for > >> IGD devices until Raptor Lake, meaning that the device list is fixed > >> for now. > >> > >> By the way, for legacy mode, I think we should only support it until > >> Gen 9, as Intel only provide VBIOS or CSM support until that generation, > >> and seabios cannot handle 64 bit BDSM register. I'm also wondering if > >> VGA really works on newer generations. > > > > If it's a VGA class device, it really should, but without CSM I could > > see why you have doubts. > > Without CSM/VBIOS there is no pre-boot video, but when it booted to OS, > driver is used for video rather than VGA. Though it claims itself as > VGA class, it does not have VGA compatiblity. A770 even does not have > IO BAR, definitely it cannot handle VGA decoding. VGA ranges are implicit in a VGA class device, they're not backed by BARs. Lack of CSM support makes it more difficult to prove whether VGA support is present since we can't easily initialize the device for a legacy OS, but I don't think lack of CSM necessary proves the hardware doesn't support VGA. If we really cared, we could probably do some low level experiments writing into the VGA frame buffer range to test if it's present and behaves as expected relative to memory and IO enable bits. > > Similar behavior is also found on AMD GPUs. They still claim as VGA > controller, but without CSM support. > https://www.amd.com/en/resources/support-articles/faqs/GPU-N4XCSM.html > > >> Maybe we can continue with current igd_gen, but implement a logic like: > >> if (!intel graphics) > >> return; > >> if (!has VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION) > >> return; > >> setup_opregion(); // make x-igd-opregion automatically enabled? > >> if (gen <= 9) > >> setup_legacy_mode(); > >> if (gen >= 6 && gen <=9) > >> setup_32bit_bdsm(): > >> else if (gen >= 9 && gen <= 12) > >> setup_64bit_bdsm(); > >> // ... > >> // optional quirks like lpc bridge id > >> > >> A table can also be used to precisely track all the gen 6-12 devices. > > > > This seems reasonable to me. > > > >> Attached a config space dump of Intel A770 discrete GPU for reference > >> > >> 03:00.0 VGA compatible controller: Intel Corporation DG2 [Arc A770] (rev > >> 08) (prog-if 00 [VGA controller]) > >> Subsystem: Intel Corporation Device 1020 > >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > >> Stepping- SERR- FastB2B- DisINTx- > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- > >> <MAbort- >SERR- <PERR- INTx- > >> Latency: 0, Cache Line Size: 64 bytes > >> Interrupt: pin ? routed to IRQ 181 > >> IOMMU group: 19 > >> Region 0: Memory at 81000000 (64-bit, non-prefetchable) [size=16M] > >> Region 2: Memory at 6000000000 (64-bit, prefetchable) [size=16G] > >> Expansion ROM at 82000000 [disabled] [size=2M] > >> Capabilities: [40] Vendor Specific Information: Len=0c <?> > >> Capabilities: [70] Express (v2) Endpoint, IntMsgNum 0 > >> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, > >> L1 <1us > >> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ > >> SlotPowerLimit 0W TEE-IO- > >> DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- > >> RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset- > >> MaxPayload 128 bytes, MaxReadReq 128 bytes > >> DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq+ AuxPwr- > >> TransPend- > >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit > >> Latency L0s <64ns, L1 <1us > > > > Hmm, hardware bug? Surely the A770 is not a Gen1, x1 device. > > Something is going on with the interrupt pin above too. At least it > > claims FLReset+ above, does it work reliably though? Seems like there > > are various reports of Arc GPUs not working well with assignment due to > > reset issues. Thanks, > > > > Alex > > Just did a quick search, link speed reporting is a known issue on Arc > A-series GPU. > https://www.intel.com/content/www/us/en/support/articles/000094587/graphics.html > > The root port reports correct `LnkSta: Speed 16GT/s, Width x16` Interesting, suppose I just hadn't noticed before. > I also tried the passthough it to VM and not meeting any reset issue. > Probably it was fixed, intel often publishes VBIOS updates (they call > it IFWI) with windows driver releases. Ok, I have an A380 that doesn't behave well with resets, I suppose I should boot it on a bare metal Windows system to try to get any available firmware updates. Thanks, Alex
