Re: [edk2-devel] The arm virtual machine displays problems in QXL during the UEFI phase

["Lange Tang" <lange_tang@163.com>]

[-- Attachment #1: Type: text/plain, Size: 5488 bytes --]

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" <kraxel@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
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 6288 bytes --]