Bug 1707119

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?

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

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

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

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

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.

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

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

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?

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

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