On Tue, Aug 22, 2023 at 04:05:09PM +0200, Mario Marietto wrote:
> Where does libvirt want to find those files ? since the qemu 5.1
> installation files have been placed under /usr/local during the command
> make install,I have also copied the firmware files in :
>
> ls /usr/local/share/AAVMF
>
> AAVMF32_CODE.fd AAVMF_CODE.fd AAVMF_CODE.snakeoil.fd AAVMF_VARS.ms.fd
> AAVMF32_VARS.fd AAVMF_CODE.ms.fd AAVMF_VARS.fd
> AAVMF_VARS.snakeoil.fd
>
> but they aren't still recognized.
Downgrading libvirt would not help in this specific case. Since version
5.2.0 libvirt uses firmware auto-selection. Libvirt is looking for json
files describing available firmwares. It is documented in QEMU project
git repository in `docs/interop/firmware.json`, this specific section
describes where the json files should be placed:
# It is recommended to create firmware JSON files (each containing a
# single @Firmware root element) with a double-digit prefix, for example
# "50-ovmf.json", "50-seabios-256k.json", etc, so they can be sorted in
# predictable order. The firmware JSON files should be searched for in
# three directories:
#
# - /usr/share/qemu/firmware -- populated by distro-provided firmware
# packages (XDG_DATA_DIRS covers
# /usr/share by default),
#
# - /etc/qemu/firmware -- exclusively for sysadmins' local additions,
#
# - $XDG_CONFIG_HOME/qemu/firmware -- exclusively for per-user local
# additions (XDG_CONFIG_HOME
# defaults to $HOME/.config).
It doesn't matter where the *CODE* and *VARS* firmware files are placed
if the path to these files is correct in the json files in one of the
three directories.
Looking at the qemu-efi-arm package it should install
/usr/share/AAVMF/AAVMF32_CODE.fd
/usr/share/AAVMF/AAVMF32_VARS.fd
/usr/share/qemu/firmware/60-edk2-arm.json
and that should be picked up correctly by libvirt.
I don't know what machine types are available for 32bit ARM, but you
should be able to figure that out by running:
virsh capabilities | grep canonical
it will show only lines with machine types, but my guess is on arm there
should be 'virt' machine type so running
virsh domcapabilities --machine virt --emulatorbin /path/to/qemu-system-arm
where you should be able to see the firmware paths if they are correctly
detected by libvirt.
Pavel
> On Tue, Aug 22, 2023 at 3:55 PM Mario Marietto <marietto2008@xxxxxxxxx>
> wrote:
>
> > I've already did that :
> >
> > # apt install qemu-efi-arm
> >
> > Reading package lists... Done
> > Building dependency tree... Done
> > Reading state information... Done
> > qemu-efi-arm is already the newest version (2022.11-6).
> > qemu-efi-arm set to manually installed.
> >
> > if I don't get wrong,that package do the installation of the following
> > files :
> >
> > root@devuan:/usr/share/AAVMF# ls
> >
> > AAVMF32_CODE.fd AAVMF_CODE.fd AAVMF_CODE.snakeoil.fd
> > AAVMF_VARS.ms.fd
> > AAVMF32_VARS.fd AAVMF_CODE.ms.fd AAVMF_VARS.fd
> > AAVMF_VARS.snakeoil.fd
> >
> > in my case they have been correctly placed under /usr/share/AAVMF
> >
> > I'm not sure that the problem is there. The error message talks about the
> > libvirt version that could be wrong. What about if I retrocede libirt 7.0
> > to 6.9 for example. Why 6.9 ?
> >
> >
> > As you can read below,it supports qemu 5.0 and newer...
> >
> > v6.9.0 (2020-11-02)
> >
> > -
> >
> > *New features*
> > -
> >
> > nodedev: Add support for channel subsystem (CSS) devices on S390
> >
> > A CSS device is represented as a parent device of a CCW device.
> > This support allows to create vfio-ccw mediated devices with
> > virNodeDeviceCreateXML().
> > -
> >
> > qemu: Implement memory failure event
> >
> > New event is implemented that is emitted whenever a guest
> > encounters a memory failure.
> > -
> >
> > qemu: Implement support for <transient/> disks
> >
> > VMs based on the QEMU hypervisor now can use <transient/> option
> > for local file-backed disks to configure a disk which discards changes made
> > to it while the VM was active.
> > -
> >
> > hyperv: implement new APIs
> >
> > The virConnectGetCapabilities(), virConnectGetMaxVcpus(),
> > virConnectGetVersion(), virDomainGetAutostart(),
> > virDomainSetAutostart(), virNodeGetFreeMemory(), virDomainReboot(),
> > virDomainReset(), virDomainShutdown(), and virDomainShutdownFlags()
> > APIs have been implemented in the Hyper-V driver.
> > -
> >
> > bhyve: implement virtio-9p filesystem support
> >
> > Implement virito-9p shared filesystem using the <filesystem/>
> > element.
> > -
> >
> > qemu: Add support for vDPA network devices.
> >
> > VMs using the QEMU hypervisor can now specify vDPA network devices
> > using <interface type='vdpa'>. The node device APIs also now list
> > and provide XML descriptions for vDPA devices.
> > -
> >
> > cpu_map: Add EPYC-Rome CPU model
> >
> > *It's supported in QEMU 5.0.0 and newer.*
> > -
> >
> > cpu: Add a flag for XML validation in CPU comparison
> >
> > The virConnectCompareCPU and virConnectCompareHypervisorCPU API now
> > support the VIR_CONNECT_COMPARE_CPU_VALIDATE_XML flag, which
> > enables XML validation. For virsh, this feature is enabled by passing the
> > --validate option to the cpu-compare and hypervisor-cpu-compare
> > subcommands.
> > -
> >
> > qemu: Introduce virtio-balloon free page reporting feature
> >
> > Introduce the optional attribute free-page-reporting for virtio
> > memballoon device. It enables/disables the ability of the QEMU virtio
> > memory balloon to return unused pages back to the hypervisor. QEMU 5.1 and
> > newer support this feature.
> > -
> >
> > *Improvements*
> > -
> >
> > qemu: Make 'cbitpos' & 'reducedPhysBits' attrs optional
> >
> > Libvirt probes the underlying platform in order to fill in these
> > SEV attributes automatically before launching a guest.
> > -
> >
> > util: support device stats collection for SR-IOV VF hostdev
> >
> > For SR-IOV VF hostdevs, libvirt now supports retrieving device
> > traffic stats via the virDomainInterfaceStats API and virsh
> > domifstat.
> > -
> >
> > logging: Allow disabling log rollover
> >
> > Set max_len=0 in virtlogd.conf to disable log rollover.
> > -
> >
> > qemu: Set noqueue qdisc for TAP devices
> >
> > Set noqueue instead of the former pfifo_fast queue discipline for
> > TAP devices. It will avoid needless cost of host CPU cycles and thus
> > improve performance.
> > -
> >
> > qemu: virtiofs can be used without NUMA nodes
> >
> > Virtiofs is supported for the VM without NUMA nodes but configured
> > with shared memory.
> > -
> >
> > *Bug fixes*
> > -
> >
> > hyperv: ensure WQL queries work in all locales
> >
> > Relying on the "Description" field caused queries to fail on
> > non-"en-US" systems. The queries have been updated to avoid using localized
> > strings.
> > -
> >
> > rpc: Fix virt-ssh-helper detection
> >
> > libvirt 6.8.0 failed to correctly detect the availability of the
> > new virt-ssh-helper command on the remote host, and thus always
> > used the fallback instead; this has now been fixed.
> >
> >
> > What do you think ? Can you share some documentation about how to
> > recompile an older version of libvirt from source code ? thanks.
> >
> > On Tue, Aug 22, 2023 at 3:35 PM Pavel Hrdina <phrdina@xxxxxxxxxx> wrote:
> >
> >> On Tue, Aug 22, 2023 at 02:49:05PM +0200, Mario Marietto wrote:
> >> > Hello to everyone.
> >> >
> >> > I'm trying to use qemu 5.1 with virt-manager and libvirt on my ARM
> >> > chromebook (armhf 32 bit cpu) running with Devuan 4 as host o.s.
> >> >
> >> > By default it uses qemu and its dependencies,version 5.2. I remember
> >> that I
> >> > can't use qemu 5.2,because it doesn't have any support for KVM as you
> >> can
> >> > read here :
> >> >
> >> >
> >> > https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg02074.html
> >> >
> >> >
> >> > For this reason,I've compiled qemu 5.1 from source. Below I shown how I
> >> > have configured everything such as a little piece of compilation
> >> messages :
> >> >
> >> >
> >> > # apt install libgtk-3-dev libpulse-dev libgbm-dev libspice-protocol-dev
> >> > libspice-server-dev libusb-1.0-0-dev libepoxy-dev
> >> >
> >> >
> >> > # cp /root/Desktop/qemu-v5.1.0/arm-softmmu/qemu-system-arm /usr/bin
> >> >
> >> > # CFLAGS=-Wno-error ./configure --target-list=x86_64-softmmu
> >> --enable-opengl
> >> > --enable-gtk --enable-kvm --enable-guest-agent --enable-spice
> >> --audio-drv-
> >> > list="oss pa" --enable-libusb
> >> >
> >> >
> >> > A little piece of the log messages that I've got from the compilation of
> >> > qemu 5.1 :
> >> >
> >> >
> >> > https://pastebin.ubuntu.com/p/8DYfgPvhXy/
> >> >
> >> >
> >> > These are the resulting versions of my frankenstein operation :
> >> >
> >> >
> >> > # virsh version
> >> >
> >> > Compiled against library: libvirt 7.0.0
> >> > Using library: libvirt 7.0.0
> >> > Using API: QEMU 7.0.0
> >> > Running hypervisor: QEMU 5.1.0
> >> >
> >> >
> >> > At this point I ran virt-manager. It has been able to detect qemu,but I
> >> get
> >> > the following error :
> >> >
> >> >
> >> > Warning : Failed to set up UEFI.
> >> > The Libvirt version does not support UEFI.
> >> > Install options are limited.
> >> >
> >> > (I have also tried upgrading devuan 4 with devuan 5 and I've got the
> >> same
> >> > error :
> >>
> >> You most likely need to install qemu-efi-arm package which should
> >> provide 32bit arm firmware files. The package name is a bit confusing
> >> as it doesn't originate from qemu project, it is from edk2 project.
> >>
> >> Without this package libvirt most likely doesn't report any efi files
> >> and that's what causes the error you are hitting.
> >>
> >> Pavel
> >>
> >> >
> >> >
> >> > root@devuan:/usr/bin# virsh version
> >> >
> >> > Compiled against library: libvirt 9.0.0
> >> > Using library: libvirt 9.0.0
> >> > Using API: QEMU 9.0.0
> >> > Running hypervisor: QEMU 5.1.0
> >> >
> >> >
> >> > If I change qemu-system-arm vers. 5.1 with qemu-system-arm 5.2,the error
> >> > disappears. So,it seems that libvirt does not accept qemu-system-arm
> >> vers.
> >> > 5.1 or maybe any version lower than 5.2,I don't know. But as I've said,I
> >> > can't use any version of qemu greater or equal to 5.2 on my setup. And I
> >> > want to use virt-manager and libvirt because I find these tools very
> >> > comfortable instead of using the "raw" qemu parameters. Is there a
> >> > workaround ? Maybe I can recompile virt-manager and / or libvirt from
> >> the
> >> > source code ? but how ? Do you think that it could work if I use
> >> something
> >> > like this (if it exists and if it can be reached in some way) :
> >> >
> >> >
> >> > Compiled against library: libvirt 5.0.0
> >> > Using library: libvirt 5.0.0
> >> > Using API: QEMU 5.0.0
> >> > Running hypervisor: QEMU 5.1.0
> >> >
> >> >
> >> > thanks.
> >> >
> >> > --
> >> > Mario.
> >>
> >
> >
> > --
> > Mario.
> >
>
>
> --
> Mario.
Attachment:
signature.asc
Description: PGP signature
