Hi,

On Thu, Jun 05, 2025 at 03:22:28PM +0200, Bastian Blank wrote:

Control: severity -1 serious

On Wed, Jun 04, 2025 at 10:29:09PM +0200, Bastian Blank wrote:

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.

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?

Why would we disable kvm in the kernel in that case, just because qemu
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/18/25 10:14 AM, Michael Tokarev wrote:

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

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

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)