Re: [PATCH V2] hw/arm: enable qxl for aarch64

[Peter Maydell]

On Mon, 15 May 2023 at 09:52, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Fri, May 12, 2023 at 05:31:08PM +0800, Hao Zeng wrote:
> > Qemu does not support qxl graphics cards in arm, it is recommended to enable
>
> Who recommends this and why ?
>
> The recommendations from Gerd are what I tend to point poeple to
> for display devices:
>
>   https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
>
> and it had this to say about arm:
>
>   "On arm systems display devices with a pci memory bar do
>    not work, which reduces the choices alot. We are left with:
>
>     virtio gpu, if your guest has drivers
>     ramfb"
>
> Not sure if anything has changed in this respect ?

That statement was not exactly correct in 2019. The
accurate statement would be:

If:
 * you're using KVM on Arm (TCG is fine)
 * and your host CPU does not have FEAT_S2FWB (a feature
   which is mandatory from Armv8.4 onwards)
 * and the guest device driver maps the PCI memory BAR
   as non-cacheable memory, or as write-through cacheable
   (which a real-hw graphics card driver will do)

then the behaviour will not be correct.

The only change since 2019 is that systems with FEAT_S2FWB
are more likely to be actually available now :-)

This happens because QEMU and the guest disagree about
the cacheability attribute for the emulated frame buffer:
to QEMU this is always normal writeback cacheable memory,
because it's just memory we got from malloc() or mmap().
The guest of course thinks it's a real hw framebuffer and
wants to map it with the attributes a hw framebuffer would have.
FEAT_S2FWB allows the hypervisor to overrule the guest's
stage 1 cacheability settings and enforce that RAM from
the host is always cacheable, which is why it avoids the issue.

For TCG none of this is a problem because the guest's
emulated memory accesses to host memory via emulation and
what the guest sets the cacheable attributes to has no effect.

The simple approach for KVM if you need to run it on
pre-v8.4 host CPUs is to use a device where the guest
device driver treats the memory as normal cacheable,
which includes the virtio-gpu one, but not any real
VGA hardware devices. A virtualization-aware graphics
device likely has other useful features in the VM
usecase anyway.

thanks
-- PMM