[Pkg-libvirt-maintainers] Bug#1120807: Bug#1120807: virt-install: fails to create ppc64el machines due to page size choice

[Andrea Bolognani]

On Tue, Nov 18, 2025 at 08:24:46AM +0100, Helmut Grohne wrote:
> On Tue, Nov 18, 2025 at 08:04:08AM +0100, Bastian Blank wrote:
> > On Sun, Nov 16, 2025 at 08:20:31AM +0100, Helmut Grohne wrote:
> > > I tried using virt-install to create a ppc64el kvm virtual machine. This 
> > > fails with an error relayed from qemu:
> > > | Can't support 64 kiB guest pages with 4 kiB host pages with this KVM implementation
> > 
> > This is a bug in qemu, see #1107288.
> 
> As far as I read that bug, this is being disputed and does not look like 
> it is being fixed there. The reasoning roughly goes like qemu wants to 
> have repeatable behavior. I note that users can already opt out of 
> repeatable behavior e.g. via -cpu max. Indeed, if you were to create a 
> VM with a 64kiB kernel and then run it in autodetection, it might work 
> or not.
> 
> Generally, qemu seems to have very user-unfriendly defaults in a lot of 
> areas. For instance, the default for -m is 128M. There are reasons for 
> that, but to me it seems like it is to be expected that users have to 
> override a lot of parameters to make it practically useful (which is 
> what e.g. debvm does).
> 
> Conversely, my impression is that higher level interfaces (debvm, 
> libvirt) are expected to paper over this and to me that includes the 
> page size matter at hand. I'm not sure virt-install should autodetect 
> this, but I think it should expose it in a way that does require 
> --qemu-commandline.
> 
> At the same time, I relate to the view that maybe qemu could out of its 
> way and provide the user with an explicit choice of "yes, I want an 
> unpredictable page size" while not making that the default.

With my upstream libvirt developer hat on, I have to disagree with
the notion that QEMU tries particularly hard to guarantee out of the
box migration compatibility, or even just guest ABI stability.

Trivial example: named machine types such as pseries are aliases to
the most recent of their versioned counterparts, so depending on the
QEMU version you're using the same command line (-machine pseries)
will result in potentially wildly different virtual hardware.

libvirt, on the other hand, puts a lot of emphasis on providing a
stable guest ABI, and in order to do so it records in the domain XML
many information such as the exact versioned machine type or the
complete PCI topology.

For the problem at hand, the example set by GIC could be followed.
Roughly speaking, this is what it would look like:

  * QEMU grows a new query-hpt-capabilities QMP command, which
    returns a list of usable page sizes;

  * libvirt picks the best one based on some criteria, e.g. the
    largest one in order to provide compatibility with the most guest
    kernels, whether they are 4k or 64k;

  * libvirt records this information in the domain XML so that it
    can be passed to QEMU for all subsequent boots as well as during
    migration.

QEMU will still not work without additional arguments, but libvirt
and applications built on top of it will.

None of this is particularly complicated and there is plenty of
precedent to draw inspiration from, but someone would have to
dedicate the time to writing the QEMU and libvirt patches.

-- 
Andrea Bolognani <eof at kiyuko.org>
Resistance is futile, you will be garbage collected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-libvirt-maintainers/attachments/20251119/4d1ab213/attachment.sig>