Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1270418 > unrolled thread

Bug#1120807: virt-install: fails to create ppc64el machines due to page size choice

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1120807: virt-install: fails to create ppc64el machines due to page size choice Helmut Grohne <helmut@subdivi.de> - 2025-11-16 18:20 +0100
    Bug#1120807: [Pkg-libvirt-maintainers] Bug#1120807: virt-install: fails to create ppc64el machines due to page size choice Andrea Bolognani <eof@kiyuko.org> - 2025-11-16 23:20 +0100
    Bug#1120807: virt-install: fails to create ppc64el machines due to page size choice Bastian Blank <waldi@debian.org> - 2025-11-18 08:10 +0100
      Bug#1107288: Bug#1120807: virt-install: fails to create ppc64el machines due to page size choice Helmut Grohne <helmut@subdivi.de> - 2025-11-18 10:20 +0100
        Bug#1107288: [Pkg-libvirt-maintainers] Bug#1120807: virt-install: fails to create ppc64el machines due to page size choice Andrea Bolognani <eof@kiyuko.org> - 2025-11-19 02:50 +0100

#1270418 — Bug#1120807: virt-install: fails to create ppc64el machines due to page size choice

Package: virt-install
Version: 1:5.0.0-5+deb13u1
X-Debbugs-Cc: debian-powerpc@lists.debian.org, mjt@debian.org
User: debian-powerpc@lists.debian.org
Usertags: ppc64el

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.

    --machine=pseries "--qemu-commandline=-machine pseries,cap-hpt-max-page-size=4096"

Would it be possible for virt-install to support this use case in a more 
convenient way? For instance, it could detect the host's page size and 
adjust it itself or it could enable passing such options via --machine.

Thanks for considering

Helmut

[toc] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Sun, Nov 16, 2025 at 08:20:31AM +0100, Helmut Grohne wrote:
> Package: virt-install
> Version: 1:5.0.0-5+deb13u1
> X-Debbugs-Cc: debian-powerpc@lists.debian.org, mjt@debian.org
> User: debian-powerpc@lists.debian.org
> Usertags: ppc64el
> 
> 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.
> 
>     --machine=pseries "--qemu-commandline=-machine pseries,cap-hpt-max-page-size=4096"
> 
> Would it be possible for virt-install to support this use case in a more 
> convenient way? For instance, it could detect the host's page size and 
> adjust it itself or it could enable passing such options via --machine.
> 
> Thanks for considering

So, a few things.

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.

-- 
Andrea Bolognani <eof@kiyuko.org>
Resistance is futile, you will be garbage collected.

[toc] | [prev] | [next] | [standalone]

#1270610

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.

Bastian

-- 
Deflector shields just came on, Captain.

[toc] | [prev] | [next] | [standalone]

#1270621 — Bug#1107288: Bug#1120807: virt-install: fails to create ppc64el machines due to page size choice

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.

Helmut

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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@kiyuko.org>
Resistance is futile, you will be garbage collected.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web