Re: [Qemu-devel] [PATCH v2] configure: enable --s390-pgste linker option

[Christian Ehrhardt]

On Wed, Aug 23, 2017 at 8:53 AM, Christian Borntraeger <
address@hidden> wrote:

> KVM guests on s390 need a different page table layout than normal
> processes (2kb page table + 2kb page status extensions vs 2kb page table
> only). As of today this has to be enabled via the vm.allocate_pgste
> sysctl.
>
> Newer kernels (>= 4.12) on s390 check for an S390_PGSTE program header
> and enable the pgste page table extensions in that case. This makes the
> vm.allocate_pgste sysctl unnecessary. We enable this program header for
> the s390 system emulation (qemu-system-s390x) if we build on s390
> - for s390 system emulation
> - the linker supports --s390-pgste (binutils >= 2.29)
> - KVM is enabled
>
> This will allow distributions to disable the global vm.allocate_pgste
> sysctl, which will improve the page table allocation for non KVM
> processes as only 2kb chunks are necessary.
>

Hi Christian,
it is great to see context pgste come to life.
Currently vm.allocate_pgste defaults to 0 in the kernel but as you stated
mostly enabled for KVM support in Distros.
So when someone wants to disable it he has to drop the enabling
(e.g. /etc/sysctl.d/10-arch-specific.conf for us).

I want to be sure on the proper phasing of this - we can drop the
"enabling" of global pgste once for a release we:
- do not expect/support a kernel <4.12 to run there
- will have only qemu versions >= the one carrying this change (and have it
properly enabled)
- binutils >= 2.29 to get the linking right

But furthermore if we have a qemu with this enabled, there is no drawback
and we could still run it in:
- former releases with older kernels
- former releases with older build environments
That program header would just be ignored and we just would have to keep
the sysctl enabled there right?

Also for the time we want to check on the proper header, you surely have a
one liner you can share that you run against the binary to check if it was
generated correctly?
Maybe even one that you can run against a pid if the status is correct?