On 2023/04/23 20:31, Michael Tokarev wrote:
23.04.2023 14:22, Akihiko Odaki пишет:
On 2023/04/23 19:28, Michael Tokarev wrote:
20.04.2023 08:29, Akihiko Odaki wrote:
On 2023/04/19 16:32, Michael Tokarev wrote:
Hello!
Today I discovered an interesting issue here: I copied a
system-installed
binary into another directory, in order to debug an unrelated
issue. Just
to discover it does not work, being unable to find any modules or data
files.
Here's how the strace of typical qemu-system-i386 run looks like (the
relevant parts only):
access("/tmp/qemu-bundle", R_OK) = -1 ENOENT (No such file or
directory)
access("/tmp/b/../lib/x86_64-linux-gnu/qemu/accel-tcg-i386.so",
F_OK) = -1 ENOENT (No such file or directory)
access("/var/run/qemu/Debian_1_8.0~rc4+dfsg-3/accel-tcg-i386.so",
F_OK) = -1 ENOENT (No such file or directory)
(the executable in this case is in /tmp, obviously). And it fails
with
error "fatal: could not load module for type 'tcg-accel-ops'".
This is despite the fact that qemu has been configured with proper
--libdir
and other --foodir to point to actual dirs such as /usr/lib
/usr/share etc.
Some files in QEMU installation is closely coupled with the binary
so it does not make much sense to copy only the executable to
another directory. You need to copy all of the files QEMU owns to
relocate a QEMU installation. QEMU uses relative paths to find such
relocated files.
That said, it is indeed confusing that QEMU uses relative paths even
if you specify an absolute path for --libdir. I prefer to require to
specify relative paths for --libdir and other options to make a QEMU
installation relocatable, but I didn't dare making such a breaking
change.
Well, quite often it makes little sense still.
For example, in debian we had to (temporarily) move qemu-system-i386
from
/usr/bin/ to /usr/libexec/, replacing the /usr/bin/ one with a shell
wrapper
(to decouple xen hvm build out of main qemu build). It was just by a
chance
the directory nesting is the same still, - I wanted to move it to
/usr/lib/qemu/
instead. But at least this one still works. Ditto for the actual
xen version,
the binary is in /usr/libexec/qemu-system-i386-xen now, I was about
to move it
to /usr/libexec/xen/qemu-system-i386 instead.
I see absolutely no reason for the binary to look into
/usr/libexec/share/qemu/bios.bin
if it is told to get all data files from /usr/share/qemu/.
What about specifying --bindir=/usr/libexec/xen?
It will try to find other binaries in /usr/libexec/xen/, which are
actually in
/usr/bin.
So you want to place only qemu-system-i386 (and perhaps
qemu-system-x86_64?) into /usr/libexec/xen but others in /usr/bin? That
scenario is certainly not covered with the current QEMU and it will need
to be patched for it.
As you say, data files are not tightly coupled with QEMU version and
it is quite possible to run QEMU with data files from another QEMU
version.
Nope and nope: first, I never said it (it was you who said that), and
second,
it is quite okay to mix-n-match data files with qemu binaries. We're way
past
the times when each minor qemu release required its own build of vgabios.
If we're to require qemu-version-specific data dir, it would be something
like /usr/share/qemu/$qemu_version/bios.bin.
I think we don't have any disagreement here. Data files are *not*
specific to a QEMU version, and you *can* just use the same data files
for different QEMU versions. No need for qemu-version-specific data dir.
However it's not true for all files QEMU installs. Especially module
files like accel-tcg-i386.so are tightly coupled with the executable
and QEMU is not expected to work if the exact modules which came with
the executable are not provided.
The .so files are different. There are also other modules (block-iscsi.so).
*Those* are already in version-specific subdir of a lbdir.
So that is how QEMU is configured for Debian? That's perfectly
legitimate, but not all distributions do that.
Also, that works only if the version changed. For example, consider the
case where you patched a module downstream. To compare the behaviors of
the patched and unpatched ones, you'll need to copy the modules
somewhere else.
I think I'll just remove this (very questionable) behavior at least
from the
Debian package. I already patched out the previous version of this,
when
it looked at ${exe_path}/../pc-bios - this at least made sense when we
needed to find firmware files for just-built qemu, in the source dir.
But
it makes no sense (in my opinion) to do that for the installed version.
It uses qemu-bundle directory for just-built QEMU so it does not
matter for the scenario.
Yes. Still I want to be able to run tests, - this is exactly what the
older code
looking for ../pc-bios/ did, and what current qemu-bundle code does.
The scenario where this conversion for relative path makes sense is
the case you need to compare the behavior of two packaged versions of
QEMU, for example. In such case, you can extract each package into a
different directory and run them. Each QEMU executable will use
relative paths to find modules tied with it.
This is exactly what I do, - comparing qemu binaries from different
packaged
builds. And this is exactly where it fails, - because the "other" binary is
not finding the binary files even if it were built with
--qemu-datadir=/usr/share/qemu/
and all the binaries is there.
It should be the other way around: if you want this qemu to use a
non-standard
path for firmware, - say, when you extracted "another" package in a temp
dir
and need that one to use its own data dir - you run it wiht -L argument.
Let's focus on modules in this discussion. There should be no problem
with data files here. You can pick data files from a different QEMU
version and it should just work fine. And even if it unfortunately does
not work, you can still use -L option to fix it.
That's not the case for modules. Modules are coupled with the executable
so you need to copy them along with the executable and the executable
should be able to find them.
Regards,
Akihiko Odaki
Thanks,
/mjt
