> 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. > 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. 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