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

[Peter Maydell]

On Mon, 15 May 2023 at 11:54, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> > > > On Mon, 2023-05-15 at 09:52 +0100, Daniel P. Berrangé wrote:
> > > > > Overall, IMHO, we should keep QXL restricted to as few build
> > > > > scenarios
> > > > > as possible. Given the status of SPICE, possibly we'll even want to
> > > > > deprecate it on x86 eventually, not add it to more arches.
> > > > >
> > > > > What are you seeing as the compelling use case that requires QXL to
> > > > > exist on aarch64 ?
> > >
> > > >    Thank you for your answer, it made me learn a lot. No use case, just
> > > > outside customer feedback on the ARM architecture qxl use has problems,
> > > > I compiled the community qemu, found that the default does not support
> > > > qxl display, so the submitted enablement.
> > > >   I agree with you, please ignore this commit.
> > >
> > > I would still like to know why QXL isn't automatically
> > > enabled like every other PCI device...
> >
> > Historical reasons ?
>
> Yes.  Any display device with a pci memory bar is disabled on arm due
> to the caching problems.  So virtio-gpu is the best option available
> (and it IMHO still is, it works without strings attached).

They all still build as far as I can see: if you
run "qemu-system-aarch64 -device help" it lists cirrus-vga,
ati-vga, bochs-display and the rest. This is correct, too --
there's no reason to deny TCG users these devices just because
they don't work in KVM.

I'm not trying to recommend QXL particularly, I'm just
not clear (a) how technically we are arranging for it not
to be built just like any other PCI device (assuming Spice
support is present at all) or (b) whether we really want
it to not be the same as all the other available but not
necessarily recommended PCI devices. Plus however we decide
to do the Kconfig logic we should resolve the discrepancy
between what hw/i386/Kconfig does and what hw/mips/Kconfig does.
(I would tend to go for "if it can be made to work, have it
enabled, and let users decide what they want to use". We
have *lots* of things QEMU can do that are almost always
not the sensible choice...)

thanks
-- PMM