On 2018-10-23 22:02, Laszlo Ersek wrote:
On 10/23/18 15:42, Gerd Hoffmann wrote:
Hi,
Please help me see the situation better. Here's my current
understanding.
(1) QemuVideoDxe doesn't set up the VMW SVGA FIFO, and does not store
1
to the SVGA_REG_CONFIG_DONE register. And this is not a "small
missing step" -- the FIFO setup can be considered a separate
feature.
(2) We don't intend to implement the FIFO setup feature. (In
particular
because we don't intend to track changed rectangles and send
updates
via the FIFO.)
(3) The intent of the original VMW SVGA enablement patch for
QemuVideoDxe, namely commit c137d9508169, was to enable booting
some
UEFI operating systems on OVMF that had guest drivers only for
VMW
SVGA.
(4) The QEMU device model now -- since commit 104bd1dc70 -- falls
back
to stdvga (that is, Bochs) in response to QemuVideoDxe's actions.
(5) Your proposal is to set up the Bochs interface in QemuVideoDxe,
*in
addition* to the -- now dysfunctional! -- VMW SVGA interface.
Is my understanding correct?
I understand things the same way.
So, what do you think of the following approach, instead of your
currently proposed patch:
- revert commit c137d9508169 ("OvmfPkg/QemuVideoDxe: VMWare SVGA
device
support", 2017-04-07)
- revert commit 05a537945872 ("OvmfPkg/QemuVideoDxe: Helper functions
for unaligned port I/O.", 2017-04-07)
- given that QEMU provides the Bochs interface anyway, with the VMW
SVGA
device model, simply recognize the "QEMU VMWare SVGA" card, in the
"gQemuVideoCardList" array, as the QEMU_VIDEO_BOCHS_MMIO variant.
Makes sense to me.
Great, thank you.
Alternatively write a full-blown vmsvga driver which works simliar to
the virtio-gpu driver. I have my doubts this is worth the effort
though.
Right, please let us *not* do this.
Before QEMU commit 104bd1dc70, was it really *required* to use the
(now
dead) QemuVideoDxe code for VMW SVGA, or would it always have been
possible to simply use the Bochs interface, to drive the VMW SVGA
device?
I think bochs interface works works with all vmsvga version (in qemu).
Great!
Didn't test though.
That's fine; I think I haven't tested VMW SVGA, as in "ever". That's up
to people that actually use the device model. As I wrote previously,
it's quite telling that the consequences of QEMU commit 104bd1dc70,
from
release v2.10.0, are reported only now, more than a year after the
release -- VMW SVGA must not be a very popular device model.
Yuchenlin, can you then please investigate this approach, including
testing the reverts (the Bochs-only implementation) against QEMU
v2.9.1?
Sure!
Thanks,
yuchenlin
(FWIW, upstream QEMU doesn't seem to support earlier releases than
v2.10.2 any longer, according to <https://www.qemu.org/>. So even if
the
v2.9.1 test failed, maybe we shouldn't care, in *upstream* edk2. Still,
knowing the status would be useful.)
Thanks!
Laszlo
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
