qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: "Shaoqin Huang" <shahuang@redhat.com>,
	qemu-arm@nongnu.org, "Eric Auger" <eauger@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Cédric Le Goater" <clg@redhat.com>,
	qemu-devel@nongnu.org,
	"Pierrick Bouvier" <pierrick.bouvier@linaro.org>
Subject: Re: [PATCH v2] ramfb: Add property to control if load the romfile
Date: Fri, 6 Jun 2025 10:15:12 +0100	[thread overview]
Message-ID: <aEKxoAw2l3Ki9RhS@redhat.com> (raw)
In-Reply-To: <9b083ae2-3afb-43f4-8929-fc693b581a0d@linaro.org>

On Fri, Jun 06, 2025 at 11:04:34AM +0200, Philippe Mathieu-Daudé wrote:
> On 6/6/25 09:52, Daniel P. Berrangé wrote:
> > On Fri, Jun 06, 2025 at 03:02:34AM -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.
> > > 
> > > 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.
> > 
> > Can you make this a series, with an additional patch that updates the
> > current in-dev machine types to use this new property, so we're clear
> > about the proposed usage.
> > 
> > > 
> > > 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/vfio/pci.c b/hw/vfio/pci.c
> > > index 7f1532fbed..4e4759c954 100644
> > > --- a/hw/vfio/pci.c
> > > +++ b/hw/vfio/pci.c
> > > @@ -3564,6 +3564,7 @@ static const TypeInfo vfio_pci_dev_info = {
> > >   static const Property vfio_pci_dev_nohotplug_properties[] = {
> > >       DEFINE_PROP_BOOL("ramfb", VFIOPCIDevice, enable_ramfb, false),
> > > +    DEFINE_PROP_BOOL("use_legacy_x86_rom", VFIOPCIDevice, use_legacy_x86_rom, true),
> > >       DEFINE_PROP_ON_OFF_AUTO("x-ramfb-migrate", VFIOPCIDevice, ramfb_migrate,
> > >                               ON_OFF_AUTO_AUTO),
> > >   };
> 
> Alternatively with target-info API:

Don't we need to use the property in order to tie this to the
machine type ? Even if existing non-x86 machines are not using
this ROM, the fact that QEMU loaded it will impact the guest
memory layout which needs to be preserved across migration,
and thus machine type versions.


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-06  9:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-06  7:02 [PATCH v2] ramfb: Add property to control if load the romfile Shaoqin Huang
2025-06-06  7:52 ` Daniel P. Berrangé
2025-06-06  8:06   ` Cédric Le Goater
2025-06-06  8:07     ` Cédric Le Goater
2025-06-09  5:16       ` Shaoqin Huang
2025-06-10 16:00         ` Alex Williamson
2025-06-06  9:04   ` Philippe Mathieu-Daudé
2025-06-06  9:15     ` Daniel P. Berrangé [this message]
2025-06-06 16:22     ` Pierrick Bouvier
2025-06-09  3:37   ` 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=aEKxoAw2l3Ki9RhS@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=philmd@linaro.org \
    --cc=pierrick.bouvier@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).