Hello,

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

The default machine used by virt-install for ppc64el is "pseries" and it
appears to default to 64 kiB guest pages. Debian has changed (#1074217)
the kernel's page size to 4 kiB for trixie though, so that's what Debian
hosts typically use.

On the qemu side, we may change this by passing:

    -machine pseries,cap-hpt-max-page-size=4096

Now getting this option through virt-install is not obvious. Trying to
pass a machine with an option to virt-install's --machine option results
in a failure as it interprets the combination of machine and option as
the machine and has no clue about this machine.

A workaround here is passing it as a --qemu-commandline.

First of all, libvirt already exposes this capability: use

  <domain>
    <features>
      <hpt>
        <maxpagesize unit='KiB'>4</maxpagesize>
  ...

to configure it.

virt-install doesn't seem to support manipulating this value
directly though, at least based on the output of

  $ virt-install --features help

so an upstream RFE will need to be filed to make that happen.

Taking a step back though, shouldn't QEMU default to a 4k page size
when 64k cannot work on the host?

Maybe there's something in the sPAPR spec that mandates 64k as the
default, I don't know. That would be very unfortunate. Users should
really not need to be aware of this kind of detail just to get a
basic VM going.

This is a bug in qemu, see #1107288.

Bastian

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.

Helmut

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.