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" <kra...@redhat.com> 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
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#83438): https://edk2.groups.io/g/devel/message/83438
Mute This Topic: https://groups.io/mt/86764804/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
