]> git.ipfire.org Git - thirdparty/libvirt.git/commit
qemu: Don't add memballoon by default on RISC-V master
authorAndrea Bolognani <abologna@redhat.com>
Tue, 16 Jan 2024 17:51:42 +0000 (18:51 +0100)
committerAndrea Bolognani <abologna@redhat.com>
Mon, 6 Oct 2025 16:12:41 +0000 (18:12 +0200)
commitfcfd6f12c529696988fd1d2768ad4920b66ce82c
tree4d2c217cfa28c394b6e150d4521c0a4021e0b2dc
parent574d797f593ec6c22eab6684a4e8e6b16f820de3
qemu: Don't add memballoon by default on RISC-V

The idea of adding devices such as USB controllers or memory
balloons by default comes from attempting to match QEMU's own
defaults at a time when x86 was the only game in town.

The unfortunate consequence of this is that, if the user does
NOT want the device in question to be present, they have to
create a special XML element with model=none to stop libvirt.
This is counter-intuitive.

For architectures for which we've added support more recently,
such as aarch64 and loongarch64, we've generally chosen to do
the sensible thing and create very minimal guests by default.
The user is of course still able to ask for additional hardware
if they so desire.

When adding RISC-V support, we accidentally forgot to skip the
creation of the default memory balloon. Address that oversight.

This is technically a breaking change, but it's fairly safe to
apply it because:

  * it doesn't affect existing guests;
  * virt-manager will automatically add the memballoon device
    by default anyway;
  * RISC-V is still not widely used.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
src/qemu/qemu_postparse.c
tests/qemuxmlconfdata/riscv64-virt-acpi.riscv64-latest.args
tests/qemuxmlconfdata/riscv64-virt-acpi.riscv64-latest.xml
tests/qemuxmlconfdata/riscv64-virt-minimal.riscv64-latest.abi-update.args
tests/qemuxmlconfdata/riscv64-virt-minimal.riscv64-latest.abi-update.xml
tests/qemuxmlconfdata/riscv64-virt-minimal.riscv64-latest.args
tests/qemuxmlconfdata/riscv64-virt-minimal.riscv64-latest.xml