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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
