On 5/10/19 5:20 AM, Hou Qiming wrote:
> Please format the commit subject with a prefix and do not use the same
> subject for all the pacthes
> in the series, for this patch it can be something like:
I'll resend the patches with improved title lines after other issues
are cleared. Thanks for the advice.
> Will this result in a silent failure? So we need to add something to
the
> log?
Based on my experience with OVMF, the "silent failure" only happens
when the firmware is malicious. In the current workflow, the only
failure modes are:
- The firmware does not support ramfb, in which case the patch is
never reached
- The firmware fails to allocate a big framebuffer, in which case it
writes log to the serial and hangs / reboots, likely before reaching
the patch
If you insist, I can add a log. I need to ask though, what is the
standard way to change something in [PATCH 1/3]? I've never done it
before and there doesn't seem to be an easy git command for that.
No need for now, I think. Thanks for the explanations.
> It is actually a cool feature, changing the resolution following a
> display window
> resize, but sadly is not stable enough. Let's hope it will be fixed
someday.
I agree. It's kind of hard to validate everything properly...
Then again, ramfb is not exactly efficient (requiring a full screen
glTexSubImage2D every frame). After the boot screen, I feel it's
better to leave such fancy features to GVT / virtio-gl / ...
> Write an initial resolution to the configuration space on guest
reset,
> which a later BIOS / OVMF patch can take advantage of.
>
I like the idea of moving the ramfb configuration to the PCI
configuration space,
do you think is possible to move all the ramfb configuration there
so we
will
not need the fw-config file?
()
I need to clarify that when I say "configuration space", I mean the
fw-config file. What I did is to initialize that fw-config content to
the resolution specified on the command line instead of all-zeros.
ramfb is not a PCI device and I don't think it's possible to move its
configuration there. Even when it's attached to vfio-pci, it's
technically a separate thing from the guest's POV.
Got it, thanks. Is a pity ramfb is not a PCI device :), it was worth the
question anyway.
Thanks for info,
Marcel
Is this chunk related to this patch? If not, you may want to split it.
Yes. That last chunk lets the user specify an initial resolution
without an EDID when ramfb is created as `-device vfio-pci,ramfb=on`.
It can be useful when debugging GPU passthrough in EFI shell or the
Windows Recovery thing (which shows up in ramfb).
Qiming
