Re: [Qemu-devel] [PATCH 3/3] ramfb enhancement

[Marcel Apfelbaum]

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