RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1707119 - Provide information about UEFI support for guests (osinfo-db)
Summary: Provide information about UEFI support for guests (osinfo-db)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: osinfo-db
Version: 8.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.2
Assignee: Fabiano Fidêncio
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1707118 1724098
Blocks: 1753634 1753637 1753641 1753644 1753645 1753670 1754394 1754396 1919805
TreeView+ depends on / blocked
 
Reported: 2019-05-06 20:30 UTC by Ademar Reis
Modified: 2023-03-20 11:11 UTC (History)
12 users (show)

Fixed In Version: osinfo-db-20200529-1.el8
Doc Type: Enhancement
Doc Text:
Clone Of: 1707118
: 1753634 1753637 1753641 1753644 1753645 1754394 1754396 (view as bug list)
Environment:
Last Closed: 2020-11-04 03:39:07 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ademar Reis 2019-05-06 20:30:35 UTC
+++ This bug was initially created as a clone of Bug #1707118 +++

The bochs-display device is a simple display device which is similar to VGA but without legacy emulation. It should be used if the guest is running with UEFI.

This changelog from this upstream commit in QEMU has more details:

commit 765c94290863eef1fc4a67819d452cc13b7854a1
Author: Gerd Hoffmann <kraxel>
Date:   Tue May 22 18:50:55 2018 +0200

    hw/display: add new bochs-display device
    
    After writing up the virtual mdev device emulating a display supporting
    the bochs vbe dispi interface (mbochs.ko) and seeing how simple it
    actually is I've figured that would be useful for qemu too.
    
    So, here it is, -device bochs-display.  It is basically -device VGA
    without legacy vga emulation.  PCI bar 0 is the framebuffer, PCI bar 2
    is mmio with the registers.  The vga registers are simply not there
    though, neither in the legacy ioport location nor in the mmio bar.
    Consequently it is PCI class DISPLAY_OTHER not DISPLAY_VGA.
    
    So there is no text mode emulation, no weird video modes (planar,
    256color palette), no memory window at 0xa0000.  Just a linear
    framebuffer in the pci memory bar.  And the amount of code to emulate
    this (and therefore the attack surface) is an order of magnitude smaller
    when compared to vga emulation.
    
    Compatibility wise it works with OVMF (latest git master).
    The bochs-drm.ko linux kernel module can handle it just fine too.
    So UEFI guests should not see any functional difference to VGA.

Comment 1 Jonathon Jongsma 2019-08-23 20:14:31 UTC
Just to clarify, is this simply a matter of changing the default video device for domains that are configured for UEFI when no other video device is specified? Or is there something else needed here?

Comment 2 Ademar Reis 2019-08-23 22:19:12 UTC
(In reply to Jonathon Jongsma from comment #1)
> Just to clarify, is this simply a matter of changing the default video
> device for domains that are configured for UEFI when no other video device
> is specified? Or is there something else needed here?

That's my understanding. Gerd, please confirm.

Comment 3 Gerd Hoffmann 2019-08-26 07:06:34 UTC
(In reply to Jonathon Jongsma from comment #1)
> Just to clarify, is this simply a matter of changing the default video
> device for domains that are configured for UEFI when no other video device
> is specified? Or is there something else needed here?

That is correct.

Comment 4 Jonathon Jongsma 2019-08-30 14:34:38 UTC
I proposed a change for libvirt, but it was decided that this is really a better decision for a higher-level management app in conjunction with libosinfo. Re-assigning this bug to osinfo for now.

Thread: https://www.redhat.com/archives/libvir-list/2019-August/msg01300.html

Comment 5 Fabiano Fidêncio 2019-09-06 13:28:16 UTC
Few questions here:
1) Which versions of RHEL & Fedora should have support to bochs-display?
1.1) Which versions of other distros should have support to bochs-display? (I can try to figure out based on when it was released ...)
2) Does the following libvirt XML looks correct?
```
     <video>
       <model type='bochs' vram='16384' heads='1' primary='yes'/>
       <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
     </video>

```

A lspci in the guest shows me:
```
...
00:01.0 Display controller: Device 1234:1111 (rev 02)
...
```

Which matches with:
https://gitlab.com/libosinfo/osinfo-db/blob/master/data/device/pcisig.com/pci-1234-1111.xml.in

If that's correct ... now it's just a matter of decorate which systems support that and have the logic exposed on the management applications side (then we'd need bugs opened for virt-manager, GNOME Boxes, OpenStack, KubeVirt, ...)

Comment 6 Fabiano Fidêncio 2019-09-06 14:03:55 UTC
There are a few other questions that just crossed my mind:
- We want bochs-display to be the default video option when using UEFI. Does it mean it also should be the preferred one? Are we not going for QXL as the preferred one anymore?
- What's the consequences on using this on non-UEFI guests? From a simple test, it just works, but I'd like to be sure that's expected result.

The main reason of the question is that some entries (Windowses, since 95) already are marked as supporting the old VGA device (with the very same PCI id) and I'm not sure what kind of problems it could bring.

Comment 7 Gerd Hoffmann 2019-09-09 06:52:43 UTC
(In reply to Fabiano Fidêncio from comment #5)
> Few questions here:
> 1) Which versions of RHEL & Fedora should have support to bochs-display?
> 1.1) Which versions of other distros should have support to bochs-display?
> (I can try to figure out based on when it was released ...)

bochs-drm driver was added in upstream kernel 3.14 IIRC.

Both RHEL-7 and RHEL-8 have the drivers.
RHEL-6 should do fine too (using efifb).

> 2) Does the following libvirt XML looks correct?
> ```
>      <video>
>        <model type='bochs' vram='16384' heads='1' primary='yes'/>
>        <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
> function='0x0'/>
>      </video>

Yes.

(In reply to Fabiano Fidêncio from comment #6)
> There are a few other questions that just crossed my mind:
> - We want bochs-display to be the default video option when using UEFI. Does
> it mean it also should be the preferred one? Are we not going for QXL as the
> preferred one anymore?

bochs-display should be preferred over stdvga ('bochs' and 'vga' in libvirt models) on UEFI.

Both 'bochs' and 'vga' are a safe default choice if we don't know what the guest operating
system supports (thats why 'vga' is the default display device in both qemu and libvirt).

If we do know the guest os supports qxl or virtio we should continue using qxl / virtio.

(side note: For virtio it would make sense to prefer virtio-gpu-pci over virtio-vga on
            UEFI for the same reason: drop vga emulation to reduce attack surface.
            But that should probably be a separate discussion, also I think libvirt
            doesn't support picking the virtio device variant).

> - What's the consequences on using this on non-UEFI guests? From a simple
> test, it just works, but I'd like to be sure that's expected result.
> 
> The main reason of the question is that some entries (Windowses, since 95)
> already are marked as supporting the old VGA device (with the very same PCI
> id) and I'm not sure what kind of problems it could bring.

There is a vgabios for bochs-display.  Anything which calls into the vgabios
will work.  Anything which accesses vga hardware directly will fail.

Assuming vga hardware is there and accessing it directly is a no-go on UEFI,
but for BIOS guests it isn't uncommon.  So there is a noticable regression
risk.

Most linux boot loaders use vgabios and work.  The linux mode text console
(vgacon) will access the vga directly, that doesn't work.  It is typically
used for a short period of time during boot only, once bochs-drm.ko loads
you'll have a working framebuffer console (fbcon).  Assuming there is a
bochs-drm.ko driver, RHEL-6 is too old for that ...

Comment 8 Fabiano Fidêncio 2019-09-09 07:37:37 UTC
(In reply to Gerd Hoffmann from comment #7)
> (In reply to Fabiano Fidêncio from comment #5)
> > Few questions here:
> > 1) Which versions of RHEL & Fedora should have support to bochs-display?
> > 1.1) Which versions of other distros should have support to bochs-display?
> > (I can try to figure out based on when it was released ...)
> 
> bochs-drm driver was added in upstream kernel 3.14 IIRC.
> 
> Both RHEL-7 and RHEL-8 have the drivers.
> RHEL-6 should do fine too (using efifb).
> 
> > 2) Does the following libvirt XML looks correct?
> > ```
> >      <video>
> >        <model type='bochs' vram='16384' heads='1' primary='yes'/>
> >        <address type='pci' domain='0x0000' bus='0x00' slot='0x01'
> > function='0x0'/>
> >      </video>
> 
> Yes.
> 
> (In reply to Fabiano Fidêncio from comment #6)
> > There are a few other questions that just crossed my mind:
> > - We want bochs-display to be the default video option when using UEFI. Does
> > it mean it also should be the preferred one? Are we not going for QXL as the
> > preferred one anymore?
> 
> bochs-display should be preferred over stdvga ('bochs' and 'vga' in libvirt
> models) on UEFI.
> 
> Both 'bochs' and 'vga' are a safe default choice if we don't know what the
> guest operating
> system supports (thats why 'vga' is the default display device in both qemu
> and libvirt).
> 
> If we do know the guest os supports qxl or virtio we should continue using
> qxl / virtio.

Okay, good!

> 
> (side note: For virtio it would make sense to prefer virtio-gpu-pci over
> virtio-vga on
>             UEFI for the same reason: drop vga emulation to reduce attack
> surface.
>             But that should probably be a separate discussion, also I think
> libvirt
>             doesn't support picking the virtio device variant).
>

Yes, this is a different discussion. :-)
 
> > - What's the consequences on using this on non-UEFI guests? From a simple
> > test, it just works, but I'd like to be sure that's expected result.
> > 
> > The main reason of the question is that some entries (Windowses, since 95)
> > already are marked as supporting the old VGA device (with the very same PCI
> > id) and I'm not sure what kind of problems it could bring.
> 
> There is a vgabios for bochs-display.  Anything which calls into the vgabios
> will work.  Anything which accesses vga hardware directly will fail.
> 
> Assuming vga hardware is there and accessing it directly is a no-go on UEFI,
> but for BIOS guests it isn't uncommon.  So there is a noticable regression
> risk.
> 
> Most linux boot loaders use vgabios and work.  The linux mode text console
> (vgacon) will access the vga directly, that doesn't work.  It is typically
> used for a short period of time during boot only, once bochs-drm.ko loads
> you'll have a working framebuffer console (fbcon).  Assuming there is a
> bochs-drm.ko driver, RHEL-6 is too old for that ...

Okay. The fact that boch 'vga' and 'bochs' have the very same device id makes everything easier as we can just assume that *all* guests will support `Device 1234:1111`.

I'll just add this info to the entries we have and then open bugs against the management tools.

Gerd, thanks for your answer.

Comment 9 Fabiano Fidêncio 2019-09-17 11:08:23 UTC
So, what we've decided to do on libosinfo/osinfo-db side is just track whether the system supports UEFI or not. Then, management applications will have to do the logic on selecting "bochs display" whenever it makes sense.

The logic should be something like:
if uses UEFI and not supports QXL:
  return Bochs.

Ademar, what's the best way to track that? Opening a bug for GNOME Boxes, virt-install, OpenStack, RHV, and KubeVirt?

Comment 10 Ademar Reis 2019-09-17 19:19:50 UTC
(In reply to Fabiano Fidêncio from comment #9)
> So, what we've decided to do on libosinfo/osinfo-db side is just track
> whether the system supports UEFI or not. Then, management applications will
> have to do the logic on selecting "bochs display" whenever it makes sense.
> 
> The logic should be something like:
> if uses UEFI and not supports QXL:
>   return Bochs.
> 
> Ademar, what's the best way to track that? Opening a bug for GNOME Boxes,
> virt-install, OpenStack, RHV, and KubeVirt?

Yes, I don't know of any better way, unfortunately. Can you please take care of it? Thanks.

Comment 18 errata-xmlrpc 2020-11-04 03:39:07 UTC
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 (libosinfo 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/RHBA-2020:4758


Note You need to log in before you can comment on or make changes to this bug.