libvirt ACPI on unsupported machine

Hi,
thanks for the report - I'm super busy this week and on PTO afterwards.
So answers might be delayed a bit and I beg your pardon in advance.
I have asked a few friends more into arm, maybe that provides a quick help.
Otherwise I'll try to squeeze in some debugging.

Hi Enoch.
I wonder if, maybe, the definition you shared just asks for an impossible configuration.

Indeed if it wants acpi, so let us add it.

If you add
   <features>
       <acpi/>
   </features>
you will get
error: unsupported configuration: ACPI requires UEFI on this architecture

So you also need to add uefi ...

Unfortunately all my arm systems are down or unusable at the moment so I can't confirm the latter.

I've asked a few friends if they could have a look as I'm soon out for a while.

Thanks for looking into it.

1. raspi3b or similar ARM machines do not support ACPI, so the <acpi/> snippet should not exist in libvirt VM's domain XML, or it will complain this or that, refusing to start just as you'd tried. That's also why my example machine XML does not have it.

2. without the <acpi/> snippet, I see that libvirt is constructing the VM startup QEMU command with "-no-acpi"

3. with this parameter passed to QEMU, it seems that QEMU will try to set a "machine variable", which my guess is "raspi3b-machine.acpi", maybe trying to set it to 0 as disable? Given that this machine type does not support ACPI, this variable may be not defined, and thus failed to be set, and hence failed to start.

Hi Enoch,

 Christian asked me to take a peek at this but, unfortunately, what you're trying to do here is outside of my wheelhouse. Generally when I'm running KVM ARM guests, I just use the "virt" model regardless of what the underlying kit is. The virt model provides a standard UEFI/KVM system (w/ or w/o ACPI). Can you confirm that what you're after is to create an accelerated system that looks like a raspi3b, or do you just want an accelerated ARM virtual machine on your raspi board? The latter should be more straightforward.

  -dann

Hi Dann,

Thanks for looking into it. I am trying pi 3b emulation at the moment, as I want to try things out with VMs instead of the real SBC. My target is to try things out before deploying to the real SBC, hence why I want to use emulation of specific machine type. I see that most tutorial online make use of directly calling qemu-system-aarch64 instead of managing it via libvirt.

I also looked into using machine=virt: it means if I use a machine=virt VM, I should use a distro that support ARM with a EFI bootloader like ubuntu-server, right? that means only distro supporting UEFI would work... maybe I can try to move the EFI binaries across distros, though in iteslf it is another form of usage, not the one that I'd mentioned above, and it also means those distro may not work "out of box".

@Enoch: Thanks for clarifying your use case, it's clear that launching an accelerated raspi3b VM is your goal - apologies I couldn't be of more help.

Thank you for your report. From the comments it has yet to be clarified whether there is a bug here, or missing support in libvirt/qemu for your particular requirements which might be considered a Wishlist feature request.

Either way this seems like "unusual end-user configurations or uncommon hardware" so I'm setting Importance to Low. Accordingly I wouldn't expect the Ubuntu Server Team to find the time to look into this soon, but feel free to use this bug to coordinate with others also affected.

Just to clarify things a little bit. I don't believe this is actually very "unusual hardware". I try to develop software for Raspberry Pi (a common hardware platform) on my laptop and have installed QEmu to do so. If I use libvirt to start QEmu, I run into this exact same problem. Starting QEmu directly of course works and, these days, it does have support for emulating a Raspberry Pi.

If I fudge things by removing the "-no-acpi" command line option from being passed to QEmu, things work just as expected. So, I believe this could be as easy as checking the target machine type, and if it is any of the raspiXXX types, then drop this particular argument.

Status changed to 'Confirmed' because the bug affects multiple users.

I am experiencing the same error pattern on Ubuntu 22.04, while the exact same setup works as expected on Ubuntu 18.04 and Ubuntu 20.04:

<domain type='qemu'>
...
  <os>
    <type arch='aarch64' machine='vexpress-a15'>hvm</type>
    ...
...

"libvirt.libvirtError: internal error: process exited while connecting to monitor: 2022-08-29T14:02:01.589608Z qemu-system-aarch64: Property 'vexpress-a15-machine.acpi' not found"

More information about my machine:
eric@eric-VirtualBox:~/e3_emushape/Emushape$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy
eric@eric-VirtualBox:~/e3_emushape/Emushape$ uname -a
Linux eric-VirtualBox 5.15.0-46-generic #49-Ubuntu SMP Thu Aug 4 18:03:25 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
eric@eric-VirtualBox:~/e3_emushape/Emushape$ uname -m
x86_64

From what was described it seems that this is something to be requested to upstream. Have you considered filing an upstream bug?

According to libvirt's documentation, the flag "-no-acpi" will be passed whenever the <features> element does not contain <acpi>, which is exactly the case here:

https://wiki.libvirt.org/page/QEMUSwitchToLibvirt#-no-acpi

There is an upstream bug for this issue:

https://gitlab.com/libvirt/libvirt/-/issues/297

The first comment is not very encouraging, though. It seems like this feature request will be a bit more complex than initially thought.

Either way, my opinion is that this is something better done at the upstream level, and not in Ubuntu. We should keep an eye on the progress of the upstream bug.

I checked the upstream bug. No changes since Sergio's comment.

The upstream bug has been fixed. The fix should be available in mantic by now. Would anyone affected be able to confirm?

Yes I can confirm that the issue that I experienced on Ubuntu 22.04 I do not longer experience on Ubuntu 23.10. Thanks for your efforts.

Thanks for confirming, I updated the bug tasks accordingly. The upstream fix consists in this commit:

https://gitlab.com/libvirt/libvirt/-/commit/98c4e3d0732db8e1f28172cb90661f544412fc4f

however I can't immediately tell if applying it to the QEMU versions in Jammy/Lunar would be safe. In other words I am not sure this is good SRU material (see [1]), given that the impact of this bug doesn't seem to be high, and that there is a supported Ubuntu release where the bug is fixed (Mantic). This is however open for discussion.

[1] https://wiki.ubuntu.com/StableReleaseUpdates#When

I agree with Paride that given the complexity of the patch and the existence of a workaround, for this to be acceptable as SRU it will need a strong statement about the impact of the issue. It sounds like it would help to have a better understanding of the breadth of hardware affected, and how severe the problem is for those affected. Can someone help fill that in?