All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Shaoqin Huang <shahuang@redhat.com>
Cc: qemu-arm@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Eric Auger" <eauger@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Cédric Le Goater" <clg@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v3 1/2] ramfb: Add property to control if load the romfile
Date: Mon, 9 Jun 2025 10:07:11 +0100	[thread overview]
Message-ID: <aEakP3rDTyBqDXA5@redhat.com> (raw)
In-Reply-To: <20250609073408.2083831-2-shahuang@redhat.com>

On Mon, Jun 09, 2025 at 03:34:07AM -0400, Shaoqin Huang wrote:
> Now the ramfb will load the vgabios-ramfb.bin unconditionally, but only
> the x86 need the vgabios-ramfb.bin, this can cause that when use the
> release package on arm64 it can't find the vgabios-ramfb.bin.
> 
> Because only seabios will use the vgabios-ramfb.bin, load the rom logic
> is x86-specific. For other !x86 platforms, the edk2 ships an EFI driver
> for ramfb, so they don't need to load the romfile.

vgabios-ramfb.bin is just one of many VGA BIOS ROMs in QEMU

$ git grep vgabios hw/
../hw/display/ati.c:    k->romfile = "vgabios-ati.bin";
../hw/display/bochs-display.c:    k->romfile   = "vgabios-bochs-display.bin";
../hw/display/qxl.c:    k->romfile = "vgabios-qxl.bin";
../hw/display/ramfb.c:    rom_add_vga("vgabios-ramfb.bin");
../hw/display/vga-pci.c:    k->romfile = "vgabios-stdvga.bin";
../hw/display/vga_int.h:#define VGABIOS_FILENAME "vgabios.bin"
../hw/display/vga_int.h:#define VGABIOS_CIRRUS_FILENAME "vgabios-cirrus.bin"
../hw/display/virtio-vga.c:    pcidev_k->romfile = "vgabios-virtio.bin";
../hw/display/vmware_vga.c:    k->romfile = "vgabios-vmware.bin";
../hw/ppc/amigaone.c: * BIOS emulator in firmware cannot run QEMU vgabios and hangs on it, use
../hw/ppc/amigaone.c: * from http://www.nongnu.org/vgabios/ instead.
../hw/xen/xen_pt_graphics.c:static void *get_vgabios(XenPCIPassthroughState *s, int *size,
../hw/xen/xen_pt_graphics.c:    bios = get_vgabios(s, &bios_size, dev);


At least some of these devices are built into non-x86 system
emulators, and would show the same behaviour if the ROM is not
installed

$ qemu-system-aarch64  -machine virt -cpu max -device ati-vga
qemu-system-aarch64: -device ati-vga: failed to find romfile "vgabios-ati.bin"
$ qemu-system-aarch64  -machine virt -cpu max -device cirrus-vga
qemu-system-aarch64: -device cirrus-vga: failed to find romfile "vgabios-cirrus.bin"
$ qemu-system-aarch64  -machine virt -cpu max -device VGA
qemu-system-aarch64: -device VGA: failed to find romfile "vgabios-stdvga.bin"

Perhaps some of these devices are non-functional for other
reasons ?

None the less if the device is built for non-x86 targets, and
the ROM files contain x86-only code that is to be executed by
SeaBIOS only, then conceptually this fix should apply to all
devices use a VGA BIOS ROM, not just ramfb.

If we're introducing a property to control this usage, then
we should fix all devices at once, so we don't need to add
separate properties for other devices in future.

> 
> So add a new property use_legacy_x86_rom in both ramfb and vfio_pci
> device, because the vfio display also use the ramfb_setup() to load
> the vgabios-ramfb.bin file.
> 
> After have this property, the machine type can set the compatibility to
> not load the vgabios-ramfb.bin if the arch doesn't need it.
> 
> Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
> ---
>  hw/display/ramfb-standalone.c | 4 +++-
>  hw/display/ramfb-stubs.c      | 2 +-
>  hw/display/ramfb.c            | 6 ++++--
>  hw/vfio/display.c             | 4 ++--
>  hw/vfio/pci.c                 | 1 +
>  hw/vfio/pci.h                 | 1 +
>  include/hw/display/ramfb.h    | 2 +-
>  7 files changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/display/ramfb-standalone.c b/hw/display/ramfb-standalone.c
> index 1be106b57f..af1175bf96 100644
> --- a/hw/display/ramfb-standalone.c
> +++ b/hw/display/ramfb-standalone.c
> @@ -17,6 +17,7 @@ struct RAMFBStandaloneState {
>      QemuConsole *con;
>      RAMFBState *state;
>      bool migrate;
> +    bool use_legacy_x86_rom;
>  };
>  
>  static void display_update_wrapper(void *dev)
> @@ -39,7 +40,7 @@ static void ramfb_realizefn(DeviceState *dev, Error **errp)
>      RAMFBStandaloneState *ramfb = RAMFB(dev);
>  
>      ramfb->con = graphic_console_init(dev, 0, &wrapper_ops, dev);
> -    ramfb->state = ramfb_setup(errp);
> +    ramfb->state = ramfb_setup(ramfb->use_legacy_x86_rom, errp);
>  }
>  
>  static bool migrate_needed(void *opaque)
> @@ -62,6 +63,7 @@ static const VMStateDescription ramfb_dev_vmstate = {
>  
>  static const Property ramfb_properties[] = {
>      DEFINE_PROP_BOOL("x-migrate", RAMFBStandaloneState, migrate,  true),
> +    DEFINE_PROP_BOOL("use-legacy-x86-rom", RAMFBStandaloneState, use_legacy_x86_rom, true),

There are lots of ROMs, so this property name should include
some reference to vgabios, perhaps

  'use-legacy-vgabios-rom'


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


  reply	other threads:[~2025-06-09  9:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-09  7:34 [PATCH v3 0/2] ramfb: Add property to control if load the romfile Shaoqin Huang
2025-06-09  7:34 ` [PATCH v3 1/2] " Shaoqin Huang
2025-06-09  9:07   ` Daniel P. Berrangé [this message]
2025-06-10  6:47     ` Gerd Hoffmann
2025-06-16  5:52       ` Shaoqin Huang
2025-06-09  7:34 ` [PATCH v3 2/2] hw/arm: Add the romfile compatatibility Shaoqin Huang
2025-06-09  8:48   ` Peter Maydell
2025-06-09  9:10     ` Daniel P. Berrangé
2025-06-16  5:53       ` Shaoqin Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aEakP3rDTyBqDXA5@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=clg@redhat.com \
    --cc=eauger@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shahuang@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.