qemu is configured to always request 64 KiB pages on ppc64(el).  Debian
does not (longer) support this mode by default.  This means qemu needs
to automatically downgrade to 4 KiB if this is the only thing that's
supported.

Responsible AFAIK:
| smc->default_caps.caps[SPAPR_CAP_HPT_MAXPAGESIZE] = 15; /* 64kiB */

Bastian

Control: severity -1 serious

This now means that qemu with kvm is completely broken on ppc64el.  How
should we fix that?

- Breaks on the kernel, with what?
- Disable kvm in the kernel?

Bastian

Hi,
does not work with stock defaults - given that you can always disable
kvm in qemu?

Anyway: On one of the DSA machines I ran into this issue and the
Internet told me to pass "-machine pseries,cap-hpt-max-page-size=4096"
to qemu, which seems to work just fine under trixie's 4k default kernel.

It'd be great if qemu could autodetect this, i.e. presumably use
getconf(PAGE_SIZE) for this.

Kind regards
Philipp Kern

On 18.06.2025 11:02, Philipp Kern wrote:
[]

As has been explained to me by the qemu ppc people, autodetecting this
is wrong because this way qemu will start with different configuration
on different hosts, and the virtual machines will be unpredictable
non-migratable.  I don't know how important this is, though - probably
being able to start in the first place is more important.

/mjt

Aren't they non-migratable anyway if the host kernel page size config
differs? I.e. if you are already diverging there between multiple hosts,
you lost the ability to migrate because it would not be runnable either
- not just unable to start. But I surely miss something here. :)

Kind regards
Philipp Kern

Control: severity -1 normal
The point is that by default, qemu creates machines with deterministic
configuration.  If this configuration is not supported on a given HW, it
fails to start.  You have to explicitly specify a non-default config
(on all machines when you want the VM to be migratable).

It is similar to using -cpu host automatically together with -enable-kvm
-- it is a fine default as long as you don't consider migration.  So
instead, qemu uses some minimal common cpu type, and you have to
explicitly specify the cpu (on all nodes) when you know all your nodes
handles it.

Either way, I don't see why this bug has "serious" severity.  To me, it
is a wishlist severity, but let's keep it as "normal".

And either way, I don't want to divirge from the upstream here.  So it
is probably "wontfix" too.

Thanks,

/mjt

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.