From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxuAd-0006j2-J0 for qemu-devel@nongnu.org; Fri, 29 Sep 2017 08:13:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxuAa-0006Jq-DN for qemu-devel@nongnu.org; Fri, 29 Sep 2017 08:13:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43788) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dxuAa-0006JR-6j for qemu-devel@nongnu.org; Fri, 29 Sep 2017 08:13:28 -0400 Date: Fri, 29 Sep 2017 14:13:20 +0200 From: Cornelia Huck Message-ID: <20170929141320.1becfd34.cohuck@redhat.com> In-Reply-To: References: <20170927170027.8539-1-david@redhat.com> <20170929134938.18fae231.cohuck@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/3] s390x/tcg: LAP support using immediate TLB invalidation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand Cc: qemu-devel@nongnu.org, thuth@redhat.com, Christian Borntraeger , Alexander Graf , Richard Henderson List-ID: On Fri, 29 Sep 2017 14:09:04 +0200 David Hildenbrand wrote: > On 29.09.2017 13:49, Cornelia Huck wrote: > > On Wed, 27 Sep 2017 19:00:24 +0200 > > David Hildenbrand 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 > Reviewed-by: Thomas Huth > Signed-off-by: David Hildenbrand > > > The other two patches, I will resend once we know how to handle the TLB > invalidation. OK, thanks for the clarification!