accel/tcg/cputlb.c | 5 ++- accel/tcg/softmmu_template.h | 4 +- include/exec/cpu-all.h | 3 ++ target/s390x/excp_helper.c | 3 +- target/s390x/mem_helper.c | 8 ---- target/s390x/mmu_helper.c | 94 +++++++++++++++++++++++++++----------------- 6 files changed, 69 insertions(+), 48 deletions(-)
Details about Low-Address Protection can be found in description of patch 1 and 2. It is basically a subpage protection of the first two pages of every address space (for which it is enabled). We can achieve this by simply directly invalidating the TLB entry and therefore forcing every write accesses onto these two pages into the slow path. With this patch, I can boot Linux just fine (which uses LAP). This also makes all related kvm-unit-tests that we have pass. RFC -> v1: - fix LAP range check (Thomas) - SIGP fix got picked up Based on: https://github.com/cohuck/qemu.git s390-next Available on: https://github.com/dhildenb/qemu.git s390x_lap David Hildenbrand (2): accel/tcg: allow to invalidate a write TLB entry immediately s390x/tcg: low-address protection support accel/tcg/cputlb.c | 5 ++- accel/tcg/softmmu_template.h | 4 +- include/exec/cpu-all.h | 3 ++ target/s390x/excp_helper.c | 3 +- target/s390x/mem_helper.c | 8 ---- target/s390x/mmu_helper.c | 94 +++++++++++++++++++++++++++----------------- 6 files changed, 69 insertions(+), 48 deletions(-) -- 2.13.5
On Mon, 16 Oct 2017 22:23:56 +0200 David Hildenbrand <david@redhat.com> wrote: > Details about Low-Address Protection can be found in description of > patch 1 and 2. It is basically a subpage protection of the first two > pages of every address space (for which it is enabled). > > We can achieve this by simply directly invalidating the TLB entry and > therefore forcing every write accesses onto these two pages into the slow > path. > > With this patch, I can boot Linux just fine (which uses LAP). This also > makes all related kvm-unit-tests that we have pass. Tested with a kernel based on the s390/features branch (4.14-rc2 + s390 patches) and the initrd from the debian installer, had udevd shot down by the oomkiller. That happened only once, so it was probably an unrelated fluke, but that combination worked well before. [More config data + logs available on request.] > > > RFC -> v1: > - fix LAP range check (Thomas) > - SIGP fix got picked up > > Based on: https://github.com/cohuck/qemu.git s390-next > Available on: https://github.com/dhildenb/qemu.git s390x_lap > > > David Hildenbrand (2): > accel/tcg: allow to invalidate a write TLB entry immediately > s390x/tcg: low-address protection support > > accel/tcg/cputlb.c | 5 ++- > accel/tcg/softmmu_template.h | 4 +- > include/exec/cpu-all.h | 3 ++ > target/s390x/excp_helper.c | 3 +- > target/s390x/mem_helper.c | 8 ---- > target/s390x/mmu_helper.c | 94 +++++++++++++++++++++++++++----------------- > 6 files changed, 69 insertions(+), 48 deletions(-) >
On 17.10.2017 10:47, Cornelia Huck wrote: > On Mon, 16 Oct 2017 22:23:56 +0200 > David Hildenbrand <david@redhat.com> wrote: > >> Details about Low-Address Protection can be found in description of >> patch 1 and 2. It is basically a subpage protection of the first two >> pages of every address space (for which it is enabled). >> >> We can achieve this by simply directly invalidating the TLB entry and >> therefore forcing every write accesses onto these two pages into the slow >> path. >> >> With this patch, I can boot Linux just fine (which uses LAP). This also >> makes all related kvm-unit-tests that we have pass. > > Tested with a kernel based on the s390/features branch (4.14-rc2 + s390 > patches) and the initrd from the debian installer, had udevd shot down > by the oomkiller. That happened only once, so it was probably an > unrelated fluke, but that combination worked well before. > Very unlikely, on invalid programming exceptions you would get a kernel panic, not run oom. (not saying it isn't possible, rather that it is very unlikely). Can you reproduce with more memory? Have you enabled SMP? (little higher memory consumption) I am running (almost) the same setup with 500M and haven't observed any such thing. > [More config data + logs available on request.] Can you send via (private) mail? I can have a look. Thanks for testing! -- Thanks, David
On Tue, 17 Oct 2017 11:22:19 +0200 David Hildenbrand <david@redhat.com> wrote: > On 17.10.2017 10:47, Cornelia Huck wrote: > > On Mon, 16 Oct 2017 22:23:56 +0200 > > David Hildenbrand <david@redhat.com> wrote: > > > >> Details about Low-Address Protection can be found in description of > >> patch 1 and 2. It is basically a subpage protection of the first two > >> pages of every address space (for which it is enabled). > >> > >> We can achieve this by simply directly invalidating the TLB entry and > >> therefore forcing every write accesses onto these two pages into the slow > >> path. > >> > >> With this patch, I can boot Linux just fine (which uses LAP). This also > >> makes all related kvm-unit-tests that we have pass. > > > > Tested with a kernel based on the s390/features branch (4.14-rc2 + s390 > > patches) and the initrd from the debian installer, had udevd shot down > > by the oomkiller. That happened only once, so it was probably an > > unrelated fluke, but that combination worked well before. > > > > Very unlikely, on invalid programming exceptions you would get a kernel > panic, not run oom. (not saying it isn't possible, rather that it is > very unlikely). That's what I thought as well. > > Can you reproduce with more memory? Have you enabled SMP? (little higher > memory consumption) SMP is on. I could not reproduce it again... > > I am running (almost) the same setup with 500M and haven't observed any > such thing. ...so I think it really is an unrelated fluke (and I'll simply make the machine a bit larger).
On Mon, 16 Oct 2017 22:23:56 +0200 David Hildenbrand <david@redhat.com> wrote: > Details about Low-Address Protection can be found in description of > patch 1 and 2. It is basically a subpage protection of the first two > pages of every address space (for which it is enabled). > > We can achieve this by simply directly invalidating the TLB entry and > therefore forcing every write accesses onto these two pages into the slow > path. > > With this patch, I can boot Linux just fine (which uses LAP). This also > makes all related kvm-unit-tests that we have pass. > > > RFC -> v1: > - fix LAP range check (Thomas) > - SIGP fix got picked up > > Based on: https://github.com/cohuck/qemu.git s390-next > Available on: https://github.com/dhildenb/qemu.git s390x_lap > > > David Hildenbrand (2): > accel/tcg: allow to invalidate a write TLB entry immediately > s390x/tcg: low-address protection support > > accel/tcg/cputlb.c | 5 ++- > accel/tcg/softmmu_template.h | 4 +- > include/exec/cpu-all.h | 3 ++ > target/s390x/excp_helper.c | 3 +- > target/s390x/mem_helper.c | 8 ---- > target/s390x/mmu_helper.c | 94 +++++++++++++++++++++++++++----------------- > 6 files changed, 69 insertions(+), 48 deletions(-) > As the oom was not reproducible (and seems to be only a problem of the machine being run with barely enough memory), I'm inclined to queue this to s390-next after I got some acks/r-bs for patch 1.
On Tue, 17 Oct 2017 14:17:06 +0200 Cornelia Huck <cohuck@redhat.com> wrote: > On Mon, 16 Oct 2017 22:23:56 +0200 > David Hildenbrand <david@redhat.com> wrote: > > > Details about Low-Address Protection can be found in description of > > patch 1 and 2. It is basically a subpage protection of the first two > > pages of every address space (for which it is enabled). > > > > We can achieve this by simply directly invalidating the TLB entry and > > therefore forcing every write accesses onto these two pages into the slow > > path. > > > > With this patch, I can boot Linux just fine (which uses LAP). This also > > makes all related kvm-unit-tests that we have pass. > > > > > > RFC -> v1: > > - fix LAP range check (Thomas) > > - SIGP fix got picked up > > > > Based on: https://github.com/cohuck/qemu.git s390-next > > Available on: https://github.com/dhildenb/qemu.git s390x_lap > > > > > > David Hildenbrand (2): > > accel/tcg: allow to invalidate a write TLB entry immediately > > s390x/tcg: low-address protection support > > > > accel/tcg/cputlb.c | 5 ++- > > accel/tcg/softmmu_template.h | 4 +- > > include/exec/cpu-all.h | 3 ++ > > target/s390x/excp_helper.c | 3 +- > > target/s390x/mem_helper.c | 8 ---- > > target/s390x/mmu_helper.c | 94 +++++++++++++++++++++++++++----------------- > > 6 files changed, 69 insertions(+), 48 deletions(-) > > > > As the oom was not reproducible (and seems to be only a problem of the > machine being run with barely enough memory), I'm inclined to queue > this to s390-next after I got some acks/r-bs for patch 1. And as I want to send this in my last pull req before softfreeze, I included it anyway :) Thanks, applied.
© 2016 - 2024 Red Hat, Inc.