From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AEA78C352AA for ; Tue, 1 Oct 2019 08:25:01 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7D10721855 for ; Tue, 1 Oct 2019 08:25:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D10721855 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:59806 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFDSu-0007J3-Ku for qemu-devel@archiver.kernel.org; Tue, 01 Oct 2019 04:25:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55407) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFDRr-0006O0-GP for qemu-devel@nongnu.org; Tue, 01 Oct 2019 04:23:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iFDRq-0002P3-Dk for qemu-devel@nongnu.org; Tue, 01 Oct 2019 04:23:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58220) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iFDRq-0002Ou-64; Tue, 01 Oct 2019 04:23:54 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 608E930917AF; Tue, 1 Oct 2019 08:23:53 +0000 (UTC) Received: from thuth.remote.csb (ovpn-116-70.ams2.redhat.com [10.36.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id A585960C5D; Tue, 1 Oct 2019 08:23:48 +0000 (UTC) Subject: Re: [PATCH v3 7/7] s390x/mmu: Convert to non-recursive page table walk To: David Hildenbrand , qemu-devel@nongnu.org References: <20190927095831.23543-1-david@redhat.com> <20190927095831.23543-8-david@redhat.com> From: Thomas Huth Openpgp: preference=signencrypt Autocrypt: addr=thuth@redhat.com; prefer-encrypt=mutual; keydata= mQINBFH7eUwBEACzyOXKU+5Pcs6wNpKzrlJwzRl3VGZt95VCdb+FgoU9g11m7FWcOafrVRwU yYkTm9+7zBUc0sW5AuPGR/dp3pSLX/yFWsA/UB4nJsHqgDvDU7BImSeiTrnpMOTXb7Arw2a2 4CflIyFqjCpfDM4MuTmzTjXq4Uov1giGE9X6viNo1pxyEpd7PanlKNnf4PqEQp06X4IgUacW tSGj6Gcns1bCuHV8OPWLkf4hkRnu8hdL6i60Yxz4E6TqlrpxsfYwLXgEeswPHOA6Mn4Cso9O 0lewVYfFfsmokfAVMKWzOl1Sr0KGI5T9CpmRfAiSHpthhHWnECcJFwl72NTi6kUcUzG4se81 O6n9d/kTj7pzTmBdfwuOZ0YUSqcqs0W+l1NcASSYZQaDoD3/SLk+nqVeCBB4OnYOGhgmIHNW 0CwMRO/GK+20alxzk//V9GmIM2ACElbfF8+Uug3pqiHkVnKqM7W9/S1NH2qmxB6zMiJUHlTH gnVeZX0dgH27mzstcF786uPcdEqS0KJuxh2kk5IvUSL3Qn3ZgmgdxBMyCPciD/1cb7/Ahazr 3ThHQXSHXkH/aDXdfLsKVuwDzHLVSkdSnZdt5HHh75/NFHxwaTlydgfHmFFwodK8y/TjyiGZ zg2Kje38xnz8zKn9iesFBCcONXS7txENTzX0z80WKBhK+XSFJwARAQABtB5UaG9tYXMgSHV0 aCA8dGh1dGhAcmVkaGF0LmNvbT6JAjgEEwECACIFAlVgX6oCGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAAoJEC7Z13T+cC21EbIP/ii9cvT2HHGbFRl8HqGT6+7Wkb+XLMqJBMAIGiQK QIP3xk1HPTsLfVG0ao4hy/oYkGNOP8+ubLnZen6Yq3zAFiMhQ44lvgigDYJo3Ve59gfe99KX EbtB+X95ODARkq0McR6OAsPNJ7gpEUzfkQUUJTXRDQXfG/FX303Gvk+YU0spm2tsIKPl6AmV 1CegDljzjycyfJbk418MQmMu2T82kjrkEofUO2a24ed3VGC0/Uz//XCR2ZTo+vBoBUQl41BD eFFtoCSrzo3yPFS+w5fkH9NT8ChdpSlbNS32NhYQhJtr9zjWyFRf0Zk+T/1P7ECn6gTEkp5k ofFIA4MFBc/fXbaDRtBmPB0N9pqTFApIUI4vuFPPO0JDrII9dLwZ6lO9EKiwuVlvr1wwzsgq zJTPBU3qHaUO4d/8G+gD7AL/6T4zi8Jo/GmjBsnYaTzbm94lf0CjXjsOX3seMhaE6WAZOQQG tZHAO1kAPWpaxne+wtgMKthyPLNwelLf+xzGvrIKvLX6QuLoWMnWldu22z2ICVnLQChlR9d6 WW8QFEpo/FK7omuS8KvvopFcOOdlbFMM8Y/8vBgVMSsK6fsYUhruny/PahprPbYGiNIhKqz7 UvgyZVl4pBFjTaz/SbimTk210vIlkDyy1WuS8Zsn0htv4+jQPgo9rqFE4mipJjy/iboDuQIN BFH7eUwBEAC2nzfUeeI8dv0C4qrfCPze6NkryUflEut9WwHhfXCLjtvCjnoGqFelH/PE9NF4 4VPSCdvD1SSmFVzu6T9qWdcwMSaC+e7G/z0/AhBfqTeosAF5XvKQlAb9ZPkdDr7YN0a1XDfa +NgA+JZB4ROyBZFFAwNHT+HCnyzy0v9Sh3BgJJwfpXHH2l3LfncvV8rgFv0bvdr70U+On2XH 5bApOyW1WpIG5KPJlDdzcQTyptOJ1dnEHfwnABEfzI3dNf63rlxsGouX/NFRRRNqkdClQR3K gCwciaXfZ7ir7fF0u1N2UuLsWA8Ei1JrNypk+MRxhbvdQC4tyZCZ8mVDk+QOK6pyK2f4rMf/ WmqxNTtAVmNuZIwnJdjRMMSs4W4w6N/bRvpqtykSqx7VXcgqtv6eqoDZrNuhGbekQA0sAnCJ VPArerAZGArm63o39me/bRUQeQVSxEBmg66yshF9HkcUPGVeC4B0TPwz+HFcVhheo6hoJjLq knFOPLRj+0h+ZL+D0GenyqD3CyuyeTT5dGcNU9qT74bdSr20k/CklvI7S9yoQje8BeQAHtdV cvO8XCLrpGuw9SgOS7OP5oI26a0548M4KldAY+kqX6XVphEw3/6U1KTf7WxW5zYLTtadjISB X9xsRWSU+Yqs3C7oN5TIPSoj9tXMoxZkCIHWvnqGwZ7JhwARAQABiQIfBBgBAgAJBQJR+3lM AhsMAAoJEC7Z13T+cC21hPAQAIsBL9MdGpdEpvXs9CYrBkd6tS9mbaSWj6XBDfA1AEdQkBOn ZH1Qt7HJesk+qNSnLv6+jP4VwqK5AFMrKJ6IjE7jqgzGxtcZnvSjeDGPF1h2CKZQPpTw890k fy18AvgFHkVk2Oylyexw3aOBsXg6ukN44vIFqPoc+YSU0+0QIdYJp/XFsgWxnFIMYwDpxSHS 5fdDxUjsk3UBHZx+IhFjs2siVZi5wnHIqM7eK9abr2cK2weInTBwXwqVWjsXZ4tq5+jQrwDK cvxIcwXdUTLGxc4/Z/VRH1PZSvfQxdxMGmNTGaXVNfdFZjm4fz0mz+OUi6AHC4CZpwnsliGV ODqwX8Y1zic9viSTbKS01ZNp175POyWViUk9qisPZB7ypfSIVSEULrL347qY/hm9ahhqmn17 Ng255syASv3ehvX7iwWDfzXbA0/TVaqwa1YIkec+/8miicV0zMP9siRcYQkyTqSzaTFBBmqD oiT+z+/E59qj/EKfyce3sbC9XLjXv3mHMrq1tKX4G7IJGnS989E/fg6crv6NHae9Ckm7+lSs IQu4bBP2GxiRQ+NV3iV/KU3ebMRzqIC//DCOxzQNFNJAKldPe/bKZMCxEqtVoRkuJtNdp/5a yXFZ6TfE1hGKrDBYAm4vrnZ4CXFSBDllL59cFFOJCkn4Xboj/aVxxJxF30bn Organization: Red Hat Message-ID: <9a2111f7-6783-21e5-093e-b4cee30465a0@redhat.com> Date: Tue, 1 Oct 2019 10:23:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Tue, 01 Oct 2019 08:23:53 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Janosch Frank , Cornelia Huck , Halil Pasic , Christian Borntraeger , qemu-s390x@nongnu.org, Richard Henderson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 01/10/2019 10.17, David Hildenbrand wrote: >=20 >>> break; >>> case ASCE_TYPE_SEGMENT: >>> if (VADDR_REGION1_TX(vaddr) || VADDR_REGION2_TX(vaddr) || >>> @@ -253,11 +164,112 @@ static int mmu_translate_asce(CPUS390XState *e= nv, target_ulong vaddr, >>> if (VADDR_SEGMENT_TL(vaddr) > asce_tl) { >>> return PGM_SEGMENT_TRANS; >>> } >>> + gaddr +=3D VADDR_SEGMENT_TX(vaddr) * 8; >>> + break; >>> + default: >>> + g_assert_not_reached(); >> >> As far as I can see, all four cases are handled above, so this default >> case should really not be necessary here. >=20 > Yes, can drop. >=20 >> >>> + } >>> + >>> + switch (asce & ASCE_TYPE_MASK) { >>> + case ASCE_TYPE_REGION1: >>> + if (!read_table_entry(env, gaddr, &entry)) { >>> + return PGM_ADDRESSING; >>> + } >>> + if (entry & REGION_ENTRY_I) { >>> + return PGM_REG_FIRST_TRANS; >>> + } >>> + if ((entry & REGION_ENTRY_TT) !=3D REGION_ENTRY_TT_REGION1) = { >>> + return PGM_TRANS_SPEC; >>> + } >>> + if (VADDR_REGION2_TL(vaddr) < (entry & REGION_ENTRY_TF) >> 6= || >>> + VADDR_REGION2_TL(vaddr) > (entry & REGION_ENTRY_TL)) { >>> + return PGM_REG_SEC_TRANS; >>> + } >>> + if (edat1 && (entry & REGION_ENTRY_P)) { >>> + *flags &=3D ~PAGE_WRITE; >>> + } >>> + gaddr =3D (entry & REGION_ENTRY_ORIGIN) + VADDR_REGION2_TX(v= addr) * 8; >>> + /* fall through */ >>> + case ASCE_TYPE_REGION2: >>> + if (!read_table_entry(env, gaddr, &entry)) { >>> + return PGM_ADDRESSING; >>> + } >>> + if (entry & REGION_ENTRY_I) { >>> + return PGM_REG_SEC_TRANS; >>> + } >>> + if ((entry & REGION_ENTRY_TT) !=3D REGION_ENTRY_TT_REGION2) = { >>> + return PGM_TRANS_SPEC; >>> + } >>> + if (VADDR_REGION3_TL(vaddr) < (entry & REGION_ENTRY_TF) >> 6= || >>> + VADDR_REGION3_TL(vaddr) > (entry & REGION_ENTRY_TL)) { >>> + return PGM_REG_THIRD_TRANS; >>> + } >>> + if (edat1 && (entry & REGION_ENTRY_P)) { >>> + *flags &=3D ~PAGE_WRITE; >>> + } >>> + gaddr =3D (entry & REGION_ENTRY_ORIGIN) + VADDR_REGION3_TX(v= addr) * 8; >>> + /* fall through */ >>> + case ASCE_TYPE_REGION3: >>> + if (!read_table_entry(env, gaddr, &entry)) { >>> + return PGM_ADDRESSING; >>> + } >>> + if (entry & REGION_ENTRY_I) { >>> + return PGM_REG_THIRD_TRANS; >>> + } >>> + if ((entry & REGION_ENTRY_TT) !=3D REGION_ENTRY_TT_REGION3) = { >>> + return PGM_TRANS_SPEC; >>> + } >>> + if (edat1 && (entry & REGION_ENTRY_P)) { >>> + *flags &=3D ~PAGE_WRITE; >>> + } >> >> Shouldn't that check be done below the next if-statement? >=20 > Does it matter? The flags are irrelevant in case we return an exception= , > so the order shouldn't matter. Hmm, it likely does not matter, but you've got it the other way round in all other cases, so I'd vote for doing it here this way, too, for consistency. Thomas