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/helper.h | 2 +- target/s390x/mem_helper.c | 8 ---- target/s390x/misc_helper.c | 7 +++- target/s390x/mmu_helper.c | 96 ++++++++++++++++++++++++++++---------------- 8 files changed, 78 insertions(+), 50 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. The checks are working that good, that I discovered a STFL bug. STFL stores into the low addresses but low-address protection does explicitly not apply. The Linux kernel calls STFL while LAP is active. So without patch nr 3, booting Linux will fail. (this change is also part of a patch of my SMP series). Based on: https://github.com/cohuck/qemu.git s390-next Available on: https://github.com/dhildenb/qemu.git s390x_lap David Hildenbrand (3): accel/tcg: allow to invalidate a write TLB entry immediately s390x/tcg: low-address protection support s390x/tcg: make STFL store into the lowcore 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/helper.h | 2 +- target/s390x/mem_helper.c | 8 ---- target/s390x/misc_helper.c | 7 +++- target/s390x/mmu_helper.c | 96 ++++++++++++++++++++++++++++---------------- 8 files changed, 78 insertions(+), 50 deletions(-) -- 2.13.5
On Wed, 27 Sep 2017 19:00:24 +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. > > The checks are working that good, that I discovered a STFL bug. STFL > stores into the low addresses but low-address protection does explicitly > not apply. The Linux kernel calls STFL while LAP is active. So without > patch nr 3, booting Linux will fail. (this change is also part of a patch > of my SMP series). I fear I have lost track a bit with all those patches floating around. IIUC, patch 3 fixes a real bug that is only exposed by your LAP changes. It used to be part of the stfl changes in v1 of your smp series but is no longer in v2. So, is this a patch that can be applied to current s390-next? > > Based on: https://github.com/cohuck/qemu.git s390-next > Available on: https://github.com/dhildenb/qemu.git s390x_lap > > > David Hildenbrand (3): > accel/tcg: allow to invalidate a write TLB entry immediately > s390x/tcg: low-address protection support > s390x/tcg: make STFL store into the lowcore > > 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/helper.h | 2 +- > target/s390x/mem_helper.c | 8 ---- > target/s390x/misc_helper.c | 7 +++- > target/s390x/mmu_helper.c | 96 ++++++++++++++++++++++++++++---------------- > 8 files changed, 78 insertions(+), 50 deletions(-) >
On 29.09.2017 13:49, Cornelia Huck wrote: > On Wed, 27 Sep 2017 19:00:24 +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. >> >> The checks are working that good, that I discovered a STFL bug. STFL >> stores into the low addresses but low-address protection does explicitly >> not apply. The Linux kernel calls STFL while LAP is active. So without >> patch nr 3, booting Linux will fail. (this change is also part of a patch >> of my SMP series). > > I fear I have lost track a bit with all those patches floating around. > IIUC, patch 3 fixes a real bug that is only exposed by your LAP > changes. It used to be part of the stfl changes in v1 of your smp > series but is no longer in v2. So, is this a patch that can be applied > to current s390-next? > The SMP series is based on both, this series and the CPU cleanup series you already picked up. You can apply Patch 3 with the following modified description (requested by Thomas): s390x/tcg: make STFL store into the lowcore Using virtual memory access is wrong and will soon include low-address protection checks, which is to be bypassed for STFL. STFL is a privileged instruction and using LowCore requires !CONFIG_USER_ONLY, so add the ifdef and move the declaration to the right place. This was originally part of a bigger STFL(E) refactoring. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> The other two patches, I will resend once we know how to handle the TLB invalidation. >> >> Based on: https://github.com/cohuck/qemu.git s390-next >> Available on: https://github.com/dhildenb/qemu.git s390x_lap >> >> >> David Hildenbrand (3): >> accel/tcg: allow to invalidate a write TLB entry immediately >> s390x/tcg: low-address protection support >> s390x/tcg: make STFL store into the lowcore >> >> 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/helper.h | 2 +- >> target/s390x/mem_helper.c | 8 ---- >> target/s390x/misc_helper.c | 7 +++- >> target/s390x/mmu_helper.c | 96 ++++++++++++++++++++++++++++---------------- >> 8 files changed, 78 insertions(+), 50 deletions(-) >> > -- Thanks, David
On Fri, 29 Sep 2017 14:09:04 +0200 David Hildenbrand <david@redhat.com> wrote: > On 29.09.2017 13:49, Cornelia Huck wrote: > > On Wed, 27 Sep 2017 19:00:24 +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. > >> > >> The checks are working that good, that I discovered a STFL bug. STFL > >> stores into the low addresses but low-address protection does explicitly > >> not apply. The Linux kernel calls STFL while LAP is active. So without > >> patch nr 3, booting Linux will fail. (this change is also part of a patch > >> of my SMP series). > > > > I fear I have lost track a bit with all those patches floating around. > > IIUC, patch 3 fixes a real bug that is only exposed by your LAP > > changes. It used to be part of the stfl changes in v1 of your smp > > series but is no longer in v2. So, is this a patch that can be applied > > to current s390-next? > > > > The SMP series is based on both, this series and the CPU cleanup series > you already picked up. > > You can apply Patch 3 with the following modified description (requested > by Thomas): > > > s390x/tcg: make STFL store into the lowcore > > Using virtual memory access is wrong and will soon include low-address > protection checks, which is to be bypassed for STFL. > > STFL is a privileged instruction and using LowCore requires > !CONFIG_USER_ONLY, so add the ifdef and move the declaration to the > right place. > > This was originally part of a bigger STFL(E) refactoring. > > Reviewed-by: Richard Henderson <richard.henderson@linaro.org> > Reviewed-by: Thomas Huth <thuth@redhat.com> > Signed-off-by: David Hildenbrand <david@redhat.com> > > > The other two patches, I will resend once we know how to handle the TLB > invalidation. OK, thanks for the clarification!
© 2016 - 2024 Red Hat, Inc.