Hi Gerd: Thanks for your reply. >1. I wonder why the device display be normal when it hung on bus=pci.8,addr=0x0, but it is abnormal when bus=pci.9,addr=0x1 or bus=pci.7,addr=0x0. > Placing qxl behind a pci bridge is problematic too (even on x86). > I'm surprised it works at all. qxl needs io ports 0x01ce + 0x1cf for > programming video modes in vga compatibility mode, and pci bridges > typically don't pass that though. > > Maybe the working bridge got the 0x0000 -> 0x0fff io window assigned. > Wouldn't happen on x86 because of the legacy hardware in the 0x000 -> > 0x3ff range, but maybe it is used for pci-pci bridges on arm. qxl device msg as follow,when it behind bus=pci.8,addr=0x0: ``` VGA compatible controller [0300]: Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 05) (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] Physical Slot: 0-8 Flags: bus master, fast devsel, latency 0, IRQ 39 Memory at 14000000 (32-bit, non-prefetchable) [size=64M] Memory at 10000000 (32-bit, non-prefetchable) [size=64M] Memory at 18000000 (32-bit, non-prefetchable) [size=8K] I/O ports at 0000 [virtual] [size=32] Expansion ROM at 18010000 [disabled] [size=64K] Kernel driver in use: qxl Kernel modules: qxl ``` his working bridge io window as follow: ``` PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port [1b36:000c] (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 39 Memory at 19440000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0 I/O behind bridge: 00000000-00000fff [size=4K] Memory behind bridge: 10000000-180fffff [size=129M] Prefetchable memory behind bridge: 0000008000b00000-0000008000cfffff [size=2M] Capabilities: [54] Express Root Port (Slot+), MSI 00 Capabilities: [48] MSI-X: Enable+ Count=1 Masked- Capabilities: [40] Subsystem: Red Hat, Inc. Device [1b36:0000] Capabilities: [100] Advanced Error Reporting Capabilities: [148] Access Control Services Kernel driver in use: pcieport ``` qxl device msg as follow,when it behind bus=pci.9,addr=0x1: ``` VGA compatible controller [0300]: Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 05) (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] Physical Slot: 1 Flags: fast devsel, IRQ 39 Memory at 14000000 (32-bit, non-prefetchable) [size=64M] Memory at 10000000 (32-bit, non-prefetchable) [size=64M] Memory at 18000000 (32-bit, non-prefetchable) [size=8K] I/O ports at 2000 [size=32] Expansion ROM at 18010000 [disabled] [size=64K] Kernel driver in use: qxl Kernel modules: qxl ``` his working bridge io window as follow: ``` PCI bridge [0604]: Red Hat, Inc. Device [1b36:000e] (prog-if 00 [Normal decode]) Physical Slot: 0-6 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 52 Memory at 18100000 (64-bit, non-prefetchable) [size=256] Bus: primary=07, secondary=08, subordinate=08, sec-latency=0 I/O behind bridge: 00002000-00002fff [size=4K] Memory behind bridge: 10000000-180fffff [size=129M] Prefetchable memory behind bridge: [disabled] Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable+ 64bit+ Capabilities: [84] Power Management version 3 Capabilities: [48] Express PCI-Express to PCI/PCI-X Bridge, MSI 00 Capabilities: [40] Hot-plug capable Capabilities: [100] Advanced Error Reporting Kernel driver in use: shpchp ``` From the above point of view, your speculation is right. excellent! In this way, if a QXL device wants to work on ARM, the io window of the bridge it is mounted on must be allocated as 00000000-00000fff [size=4K]. In my work, by modifying the qemu code, the io window of the bridge mounted with the qxl device is fixed to 00000000-00000fff to solve this problem. what do you think? take care Lange At 2021-11-03 14:03:22, "Gerd Hoffmann" wrote: >On Wed, Nov 03, 2021 at 09:46:01AM +0800, Lange Tang wrote: >> Hi Gerd: >> Thanks for your reply. In fact, I have no choice, only QXL in my work. >> 1. I wonder why the device display be normal when it hung on bus=pci.8,addr=0x0, but it is abnormal when bus=pci.9,addr=0x1 or bus=pci.7,addr=0x0. > >Placing qxl behind a pci bridge is problematic too (even on x86). >I'm surprised it works at all. qxl needs io ports 0x01ce + 0x1cf for >programming video modes in vga compatibility mode, and pci bridges >typically don't pass that though. > >Maybe the working bridge got the 0x0000 -> 0x0fff io window assigned. >Wouldn't happen on x86 because of the legacy hardware in the 0x000 -> >0x3ff range, but maybe it is used for pci-pci bridges on arm. > >> 2. Why cache properties are going to cause QXL display abnormal on >> ARM. Are there any links or materials? Thanks. > >The fundamental issue is that the pci memory br for vram is virtual. >The guest maps it as io memory, but it actually is normal ram, so guest >and host map the same memory with different attributes. That just >doesn't work on arm and results in display corruption when actually >running on arm hardware (when running in emulation, for example using >qemu on a x86 machine, this doesn't happen). > >This is the reason why QemuVideoDxe is not compiled into ArmVirt. > >take care, > Gerd > > > > >