All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Dave <dave@0bits.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: absolute firmware path made relocatable in qemu 5.2.0
Date: Tue, 12 Jan 2021 17:53:55 +0100	[thread overview]
Message-ID: <CABgObfaZECGDvgsvebx44h84okDMKWZFw1ZtqcXk8W9SaD38Zg@mail.gmail.com> (raw)
In-Reply-To: <428592f1-a5fd-7e6a-f181-28f31343518a@0bits.com>

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

Il mar 12 gen 2021, 17:48 Dave <dave@0bits.com> ha scritto:

> Hi Paolo,
>
> While this (option 2) partially works, it will still search for
> /nonexistent/libexec/qemu-bridge-helper for example so seems that some
> paths are still absolute and some relative.
>

Ok, that's a bug that can be fixed in 5.2.1. Are there other instances?


> To explain, what we are expecting that we compile one binary with the
> relevant options, test that and then it goes into production. If we
> compile with --prefix=/usr (it's final resting place will be /usr/bin)
> then everything works as expected once it is in production (since
> /usr/share/qemu, /usr/libexec, /etc/qemu exists as expected).  However
> when we are testing the binary in a directory /root/qemu/5.2.0 with
> --prefix=/usr it breaks since it converts the firmware and bios paths to
> /root/qemu/5.2.0/../share/qemu. This means we need to recompile twice
> with relevant prefixes since if i use --prefix=/nonexistent then we
> can't find the qemu-bridge-helper when the binary goes into production.
>
> It would be nicer with the relocatable binary took some fixed paths from
> /etc/qemu.conf for the bridge-helper, firmware, bios, qemu-ifup/down.
>
> thanks
> Dave
>
>
> On 12/01/2021 18:48, Paolo Bonzini wrote:
> > On 12/01/21 15:05, Dave wrote:
> >> Is seem that absolute firmwarepath compilation option is converted  to
> >> relocatable in 5.2.0 qemu.
> >>
> >> # QEMU configure log Tue 12 Jan 14:46:41 GST 2021
> >> # Configured with: '../configure' '--prefix=/usr'
> >> '--sysconfdir=/etc/qemu' '--disable-bochs'
> >> '*--firmwarepath=/usr/share/qemu:/usr/share/qemu-firmware*'
> >> #
> >
> > Yes, all paths within the prefix are relocated.  The workaround is
> > simply to configure the intended prefix with configure:
> >
> > ./configure --prefix=/root/qemu ...
> >
> > or if you don't know the prefix:
> >
> > ./configure --prefix=/nonexistent ...
> >
> > Because /usr/share/qemu and /usr/share/qemu-firmware are outside /usr,
> > they will be treated as absolute just like /etc/qemu.
> >
> > Thanks,
> >
> > Paolo
> >
> >> And trying to run the executable
> >>
> >>     bash-5.1# ./qemu-system-x86_64
> >>     qemu: could not load PC BIOS 'bios-256k.bin'
> >>
> >> If i print out the resultant binary paths
> >>
> >>     bash-5.1# ./qemu-system-x86_64 -L help
> >>     /root/qemu/../share/qemu
> >>     /root/qemu/../share/qemu-firmware
> >>
> >> So there is no way to have a absolute path for firmware /bios and all
> >> qemu's that we test need to be at the right directory nesting to find
> >> firmware, bios etc or else they all need their own duplicate firmware
> >> files. Firmware path needs to honor the absolute paths i believe.
> >>
> >
>
>

[-- Attachment #2: Type: text/html, Size: 3789 bytes --]

  reply	other threads:[~2021-01-12 16:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12 14:05 absolute firmware path made relocatable in qemu 5.2.0 Dave
2021-01-12 14:48 ` Paolo Bonzini
2021-01-12 16:46   ` Dave
2021-01-12 16:53     ` Paolo Bonzini [this message]
2021-01-12 17:04       ` Dave
2021-01-12 19:53         ` Paolo Bonzini
2021-01-13  7:51           ` Dave
2021-01-13  8:29             ` Paolo Bonzini

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=CABgObfaZECGDvgsvebx44h84okDMKWZFw1ZtqcXk8W9SaD38Zg@mail.gmail.com \
    --to=pbonzini@redhat.com \
    --cc=dave@0bits.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.