Bug 1754396

+++ This bug was initially created as a clone of Bug #1707119 +++

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

--- Additional comment from Jonathon Jongsma on 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?

--- Additional comment from Ademar Reis on 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.

--- Additional comment from Gerd Hoffmann on 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.

--- Additional comment from Jonathon Jongsma on 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

--- Additional comment from Fabiano Fidêncio on 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, ...)

--- Additional comment from Fabiano Fidêncio on 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.

--- Additional comment from Gerd Hoffmann on 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 ...

--- Additional comment from Fabiano Fidêncio on 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.

--- Additional comment from Fabiano Fidêncio on 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?

--- Additional comment from Ademar Reis on 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.