From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, alex.bennee@linaro.org, akihiko.odaki@gmail.com
Subject: Re: [PATCH] tests/vm: do not specify -bios option
Date: Thu, 16 Jun 2022 11:29:32 +0100 [thread overview]
Message-ID: <YqsGDMENCErROHcT@redhat.com> (raw)
In-Reply-To: <9bfd73ef-749b-e9d7-9202-5ba4221c0f72@redhat.com>
On Thu, Jun 16, 2022 at 12:14:01PM +0200, Paolo Bonzini wrote:
> On 6/16/22 10:44, Daniel P. Berrangé wrote:
> > On Thu, Jun 16, 2022 at 10:30:25AM +0200, Paolo Bonzini wrote:
> > > When running from the build tree, the executable is able to find
> > > the BIOS on its own; when running from the source tree, a firmware
> > > blob should already be installed and there is no guarantee that
> > > the one in the source tree works with the QEMU that is being used for
> > > the installation.
> > I think there is interaction with
> >
> > --firmwarepath=/usr/share/qemu-firmware:/usr/share/ipxe/qemu:/usr/share/seavgabios:/usr/share/seabios:/usr/share/sgabios
> >
> > as the firmware path listed there will be searched before the local
> > build tree.
> >
> > I agree with your desire to remove the -bios option, but I'm not
> > sure it is entirely safe unless logic in qemu_find_file is fixed
> > to ignore the global search path when running from the build
> > tree.
>
> Isn't this the same for any other invocation of QEMU, for example in qtest?
Yes, quite likely in fact, so a pre-existing widespread problem and
thus not a reason to avoid this proposed change.
> I admit I didn't think of the interaction with --firmwarepath, but "if it
> hurts, don't do it" might apply here. That is, install compatible firmware
> to the path _before_ trying to use a QEMU that specifies that path.
I'm mostly thinking of downstream distro developers where they have an
installed QEMU but are working on a build from a different QEMU version.
We can address this separately though
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 :|
next prev parent reply other threads:[~2022-06-16 10:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-16 8:30 [PATCH] tests/vm: do not specify -bios option Paolo Bonzini
2022-06-16 8:44 ` Daniel P. Berrangé
2022-06-16 10:14 ` Paolo Bonzini
2022-06-16 10:29 ` Daniel P. Berrangé [this message]
2022-06-16 10:29 ` Daniel P. Berrangé
2022-06-17 8:51 ` Thomas Huth
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=YqsGDMENCErROHcT@redhat.com \
--to=berrange@redhat.com \
--cc=akihiko.odaki@gmail.com \
--cc=alex.bennee@linaro.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.