Re: [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci)

[Laszlo Ersek <lersek@redhat.com>]

On 09/01/16 21:52, Jordan Justen wrote:
> On 2016-09-01 11:46:04, Laszlo Ersek wrote:
>> On 09/01/16 20:03, Jordan Justen wrote:
>>
>>> I think there would be value to have a non-VGA device that could still
>>> configure a simple framebuffer. VGA does bring a fair amount of other
>>> baggage.
>>
>> Ah, I see your point. You distinguish "VGA" from "non-VGA device with
>> framebuffer".
>>
>> For this discussion however, this distinction makes no difference. The
>> suggested "non-VGA device with framebuffer" would be broken exactly the
>> same way. In other words, it's not the "other baggage" that is broken,
>> it is the framebuffer.
>>
> 
> This is only focusing on the current ARM issue. I'm just pointing out
> that I think virtio gpu without VGA, but with a framebuffer could be
> useful on IA32/X64 as well.

I believe your suggestion concerns the spec itself (that is, what it
should specify, and how the QEMU-side VirtIo GPU Device should be
designed). I didn't partake in the design of, nor QEMU's implementation
of, the VirtIo GPU Device, so I can't comment (Gerd Hoffmann and David
Airlie could, I assume).

The current design is certainly sufficient for the ARM issue.

> 1. You don't have to deal with the PCI bus
> 
> 2. The OS re-enumerating the PCI bus would not break the framebuffer
> 
> Is there no chance that ARM KVM might someday also be able to support
> a framebuffer?
> 
> Obviously this is not too important for IA32/X64 OVMF, because we have
> reasonable alternatives. But, it seems like virtio gpu could be a
> significantly better option for IA32/X64 OVMF if an optional
> framebuffer was possible.

Well, I can't (and shouldn't) comment, due to the above, but I might try
speculating.

If I understand correctly, you are proposing a device that is somewhere
"between" virtio-gpu-pci and virtio-vga, in the sense that it'd have a
framebuffer, but (a) the framebuffer wouldn't live in a PCI MMIO BAR,
and (b) it wouldn't have any of the other "VGA baggage".

In my experience (which may or may not be authoritative), devices that
"own" a subset of the guest-phyisical address space but are *not* PCI
devices, are platform devices. Platform devices are hard to enumerate
and to manage. They usually have ties to fw_cfg and/or ACPI and/or DT
(Device Tree). Virtio-mmio is a good example I believe.

People seem to frown upon platform devices, and prefer buses that are
enumerable via hw access (for example, virtio-pci is considered vastly
superior to virtio-mmio). In my mind (as I perceive others' opinions),
PCI is a clear winner. Arguing that a PCI graphics device present its
framebuffer differently from an MMIO BAR would be an uphill battle, I think.

But, again, as you are commenting on the design of the VirtIo GPU
Device, I'm not the right person to talk to.

Thanks
Laszlo