From patchwork Fri Oct 6 11:46:22 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxime Coquelin X-Patchwork-Id: 822369 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3y7ntl4kCFz9t41 for ; Fri, 6 Oct 2017 22:47:26 +1100 (AEDT) Received: from localhost ([::1]:44224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0R6A-0002Xb-Os for incoming@patchwork.ozlabs.org; Fri, 06 Oct 2017 07:47:22 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e0R5W-0002VW-11 for qemu-devel@nongnu.org; Fri, 06 Oct 2017 07:46:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e0R5T-0000th-Du for qemu-devel@nongnu.org; Fri, 06 Oct 2017 07:46:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41756) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e0R5T-0000se-7w; Fri, 06 Oct 2017 07:46:39 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3FF835AFC7; Fri, 6 Oct 2017 11:46:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3FF835AFC7 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=maxime.coquelin@redhat.com Received: from max-t460s.redhat.com (ovpn-112-35.ams2.redhat.com [10.36.112.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1B59964431; Fri, 6 Oct 2017 11:46:27 +0000 (UTC) From: Maxime Coquelin To: peterx@redhat.com, pbonzini@redhat.com, mst@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org Date: Fri, 6 Oct 2017 13:46:22 +0200 Message-Id: <20171006114624.10771-1-maxime.coquelin@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 06 Oct 2017 11:46:38 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH v2 0/2] exec: further refine address_space_get_iotlb_entry() X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Maxime Coquelin , qemu-stable@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" This series is a rebase of the first two patches of Peter's series improving address_space_get_iotlb_entry(): Message-Id: <1496404254-17429-1-git-send-email-peterx@redhat.com> This second revision of the rebase fixes the page_mask initial value, that was mistakenly set to its complement. This bug could only be seen when guest kernel doesn't enable iommu support, otherwise this initial value is overwritten. It is actually not only an improvement, but fixes a regression in the way IOTLB updates sent to the backends are generated. The regression is introduced by patch: a764040cc8 ("exec: abstract address_space_do_translate()") Prior to this patch IOTLB entries sent to the backend were aligned on the guest page boundaries (both addresses and size). For example, with the guest using 2MB pages: * Backend sends IOTLB miss request for iova = 0x112378fb4 * QEMU replies with an IOTLB update with iova = 0x112200000, size = 0x200000 * Bakend insert above entry in its cache and compute the translation In this case, if the backend needs later to translate 0x112378004, it will result in a cache it and no need to send another IOTLB miss. With this patch, the addr of the IOTLB entry will be the address requested via the IOTLB miss, the size is computed to cover the remaining of the guest page. The same example gives: * Backend sends IOTLB miss request for iova = 0x112378fb4 * QEMU replies with an IOTLB update with iova = 112378fb4, size = 0x8704c * Bakend insert above entry in its cache and compute the translation In this case, if the backend needs later to translate 0x112378004, it will result in another cache miss: * Backend sends IOTLB miss request for iova = 0x112378004 * QEMU replies with an IOTLB update with iova = 0x112378004, size = 0x87FFC * Bakend insert above entry in its cache and compute the translation It results in having much more IOTLB misses, and more importantly it pollutes the device IOTLB cache by multiplying the number of entries that moreover overlap. Note that current Kernel & User backends implementation do not merge contiguous and overlapping IOTLB entries at device IOTLB cache insertion. This series fixes this regression, so that IOTLB updates are aligned on guest's page boundaries. Changes since rebase: ===================== - Fix page_mask initial value - Apply Michael's on second patch Peter Xu (2): exec: add page_mask for flatview_do_translate exec: simplify address_space_get_iotlb_entry exec.c | 75 +++++++++++++++++++++++++++++++++++++++++++----------------------- 1 file changed, 49 insertions(+), 26 deletions(-)