Bug 2087220

Driver is deactivated downstream in RHEL-9 ovmf:
  3c3aea0f3737 ArmVirtPkg: Remove QemuRamfbDxe display device driver (RHEL only)
  551cf28aeedc OvmfPkg: Remove QemuRamfbDxe display device driver (RHEL only)

Why do we need ramfb support in edk2-ovmf? I've read through <https://bugzilla.redhat.com/show_bug.cgi?id=1679680> and <https://bugzilla.redhat.com/show_bug.cgi?id=1841068>, and I don't see the use case apart from AARCH64.

The original removal was due to <https://bugzilla.redhat.com/show_bug.cgi?id=1967747#c2>:

> - OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
>   (ramfb display device driver; only potentially needed for aarch64
>   Windows guests)

Commit 551cf28aeedc removed the driver from OvmfPkg DSC files, and I don't see why that's wrong.

Commit 3c3aea0f3737 removed the driver from ArmVirtPkg DSC files, and given that we don't support aarch64 Windows guests (which the commit message states, too), I don't see why that's wrong either.

The GPU assignment / vGPU case does not seem to apply to aarch64 guests at all, and on X64 guests, vga seems better <https://bugzilla.redhat.com/show_bug.cgi?id=1841068#c23>.

I had read <https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/> and <https://www.kraxel.org/blog/2019/02/ramfb-display-in-qemu/>, and I still don't have a clear understanding or statement in my mind as to why we need ramfb *in RHEL*. The original bug 1967747 was about stripping as many features as possible out of RHEL9. Thanks.

> The GPU assignment / vGPU case does not seem to apply to aarch64 guests at
> all, and on X64 guests, vga seems better
> <https://bugzilla.redhat.com/show_bug.cgi?id=1841068#c23>.

Boot display for gpu assignment is the only relevant use case indeed,
i.e. '-device vfio-pci,...,display=on,ramfb=on'

Advantage over '-device vfio-pci,...,display=on,ramfb=off -device VGA'
is that the ramfb setup tends to cause less problems on the guest side
because the guest will see only one pci display device, not two.

> The original bug 1967747 was about stripping as many
> features as possible out of RHEL9. Thanks.

Which surely makes sense for features not usable, but unfortunately
that was a bit too much.  Another case we have reverted is nvme support.
rhel qemu doesn't emulate nvme, I guess that's why it was dropped, but
pci-assigning nvme drives is a thing these days ...

That explains why we want it in OvmfPkg, but the same idea doesn't seem to apply to ArmVirtPkg -- have we ever considered assignment with VFIO on aarch64?

Well I guess we can say we want "feature parity" between OvmfPkg and ArmVirtPkg here. I don't feel especially comfortable about it, *given* bug 1967747 (i.e., given the generic feature stripping in RHEL9). While we've certainly tested ramfb itself on aarch64, I don't think we've tested GPU assignment there. Anyway, no more questions, thanks.

(In reply to Laszlo Ersek from comment #10)
> That explains why we want it in OvmfPkg, but the same idea doesn't seem to
> apply to ArmVirtPkg -- have we ever considered assignment with VFIO on
> aarch64?

Correct, on aarch64 it is not required, we could leave it disabled
for armvirt.

I'd tend to keep ovmf and armvirt in sync for consistency reasons,
and from a support point of view I think it isn't that much of a
difference whenever we support the ramfb driver on one or two
architectures.

Klaus?  Any opinion here?

> That explains why we want it in OvmfPkg, but the same idea doesn't seem to
> apply to ArmVirtPkg -- have we ever considered assignment with VFIO on
> aarch64?

Alex, what is the state of affairs in terms of pci assignment on aarch64?

Should edk2 include drivers for pci-assigned hardware (nvme for example)
in the armvirt firmware builds?

(In reply to Gerd Hoffmann from comment #11)

> 
> Klaus?  Any opinion here?

I acknowledge the desire for 'parity' and consistency, but I also recognize that we're trying to have the slimmest, lowest 'surface-area' possible. So my recommendation is to disable everywhere where it is not explicitly supported/required.

 -Klaus

(In reply to Klaus Heinrich Kiwi from comment #15)
> (In reply to Gerd Hoffmann from comment #11)
> 
> > 
> > Klaus?  Any opinion here?
> 
> I acknowledge the desire for 'parity' and consistency, but I also recognize
> that we're trying to have the slimmest, lowest 'surface-area' possible. So
> my recommendation is to disable everywhere where it is not explicitly
> supported/required.

Every time we intentionally create a difference between architectures, it has a negative ripple effect through the application stack, QE test plans and to our users. Intentionally compromising aarch64 targets by disabling features we enable on other targets further re-inforces the message that aarch64 is a secondclass citizen which is not a good thing.

WRT the intent to select a slim set of features for RHEL, this is an exercise we've aimed to apply at the package level, rather the architecture level. IOW, if we decide we don't want a particular feature make that decision for all QEMU arch targets, or none consistently.

(In reply to Daniel Berrangé from comment #16)

> WRT the intent to select a slim set of features for RHEL, this is an
> exercise we've aimed to apply at the package level, rather the architecture
> level.

Good point, thanks! (With s/package/feature/, but anyway, you use "feature" below:)

> IOW, if we decide we don't want a particular feature make that
> decision for all QEMU arch targets, or none consistently.

Good summary, this is what I've been after. I think I didn't understand this when working on bug 1967747 with Phil. Thanks!

QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.

Verify this issue against qemu-kvm-7.0.0-4.el9.x86_64 and edk2-ovmf-20220221gitb24306f15d-2.el9.noarch.

Boot rhel 9.1 VM with ramfb and check the vm screen in grub stage and desktop stage, graphic display normally.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (edk2 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:7971