qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH 3/3] ramfb enhancement
Date: Fri, 10 May 2019 09:20:27 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0



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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]