From patchwork Tue Jun 11 14:28:20 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Auger X-Patchwork-Id: 1113879 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=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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 ozlabs.org (Postfix) with ESMTPS id 45NXlY2Gmqz9sPk for ; Wed, 12 Jun 2019 00:42:17 +1000 (AEST) Received: from localhost ([::1]:59748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hahyZ-0000dO-Co for incoming@patchwork.ozlabs.org; Tue, 11 Jun 2019 10:42:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40585) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hahmH-0001WF-Cg for qemu-devel@nongnu.org; Tue, 11 Jun 2019 10:29:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hahmF-0002jt-JU for qemu-devel@nongnu.org; Tue, 11 Jun 2019 10:29:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33204) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hahmB-0002Np-8q; Tue, 11 Jun 2019 10:29:27 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3D6B78553D; Tue, 11 Jun 2019 14:28:46 +0000 (UTC) Received: from laptop.redhat.com (ovpn-116-67.ams2.redhat.com [10.36.116.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 36CCD17F41; Tue, 11 Jun 2019 14:28:43 +0000 (UTC) From: Eric Auger To: eric.auger.pro@gmail.com, eric.auger@redhat.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, peter.maydell@linaro.org Date: Tue, 11 Jun 2019 16:28:20 +0200 Message-Id: <20190611142821.3874-2-eric.auger@redhat.com> In-Reply-To: <20190611142821.3874-1-eric.auger@redhat.com> References: <20190611142821.3874-1-eric.auger@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 11 Jun 2019 14:28:46 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH 1/2] hw/arm/smmuv3: Remove spurious error messages on IOVA invalidations 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: peterx@redhat.com Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" An IOVA/ASID invalidation is notified to all IOMMU Memory Regions through smmuv3_inv_notifiers_iova/smmuv3_notify_iova. When the notification occurs it is possible that some of the PCIe devices associated to the notified regions do not have a valid stream table entry. In that case we output a LOG_GUEST_ERROR message. invalid sid= (L1STD span=0) "smmuv3_notify_iova error decoding the configuration for iommu mr= This is unfortunate as the user gets the impression that there are some translation decoding errors whereas there are not. This patch adds a new field in SMMUEventInfo that tells whether the detction of an invalid STE msut lead to an error report. invalid_ste_allowed is set before doing the invalidations and kept unset on actual translation. Signed-off-by: Eric Auger --- I also experimented to pass Error handles to all the subfunctions and handle the Error at top level but that's intricate to sort out the various kinds of errors, whether they need to be logged, and if so if they match LOG_GUEST_ERRoR mask or unimplemented mask. So I think just passing this boolean has a lesser impact on the code base. --- hw/arm/smmuv3-internal.h | 1 + hw/arm/smmuv3.c | 11 +++++------ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h index b160289cd1..d190181ef1 100644 --- a/hw/arm/smmuv3-internal.h +++ b/hw/arm/smmuv3-internal.h @@ -381,6 +381,7 @@ typedef struct SMMUEventInfo { uint32_t sid; bool recorded; bool record_trans_faults; + bool inval_ste_allowed; union { struct { uint32_t ssid; diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c index fd8ec7860e..e2f07d2864 100644 --- a/hw/arm/smmuv3.c +++ b/hw/arm/smmuv3.c @@ -404,7 +404,7 @@ static int smmu_find_ste(SMMUv3State *s, uint32_t sid, STE *ste, span = L1STD_SPAN(&l1std); - if (!span) { + if (!span && !event->inval_ste_allowed) { /* l2ptr is not valid */ qemu_log_mask(LOG_GUEST_ERROR, "invalid sid=%d (L1STD span=0)\n", sid); @@ -602,7 +602,9 @@ static IOMMUTLBEntry smmuv3_translate(IOMMUMemoryRegion *mr, hwaddr addr, SMMUDevice *sdev = container_of(mr, SMMUDevice, iommu); SMMUv3State *s = sdev->smmu; uint32_t sid = smmu_get_sid(sdev); - SMMUEventInfo event = {.type = SMMU_EVT_NONE, .sid = sid}; + SMMUEventInfo event = {.type = SMMU_EVT_NONE, + .sid = sid, + .inval_ste_allowed = false}; SMMUPTWEventInfo ptw_info = {}; SMMUTranslationStatus status; SMMUState *bs = ARM_SMMU(s); @@ -795,16 +797,13 @@ static void smmuv3_notify_iova(IOMMUMemoryRegion *mr, dma_addr_t iova) { SMMUDevice *sdev = container_of(mr, SMMUDevice, iommu); - SMMUEventInfo event = {}; + SMMUEventInfo event = {.inval_ste_allowed = true}; SMMUTransTableInfo *tt; SMMUTransCfg *cfg; IOMMUTLBEntry entry; cfg = smmuv3_get_config(sdev, &event); if (!cfg) { - qemu_log_mask(LOG_GUEST_ERROR, - "%s error decoding the configuration for iommu mr=%s\n", - __func__, mr->parent_obj.name); return; } From patchwork Tue Jun 11 14:28:21 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Auger X-Patchwork-Id: 1113872 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=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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 ozlabs.org (Postfix) with ESMTPS id 45NXhj4TYjz9s5c for ; Wed, 12 Jun 2019 00:39:49 +1000 (AEST) Received: from localhost ([::1]:59714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hahwB-0007Bt-JU for incoming@patchwork.ozlabs.org; Tue, 11 Jun 2019 10:39:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40549) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hahmC-0001UE-PJ for qemu-devel@nongnu.org; Tue, 11 Jun 2019 10:29:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hahmB-0002hO-Op for qemu-devel@nongnu.org; Tue, 11 Jun 2019 10:29:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37604) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hahm9-0002Rq-7f; Tue, 11 Jun 2019 10:29:25 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A920FC05E76E; Tue, 11 Jun 2019 14:28:50 +0000 (UTC) Received: from laptop.redhat.com (ovpn-116-67.ams2.redhat.com [10.36.116.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id B8707608CD; Tue, 11 Jun 2019 14:28:47 +0000 (UTC) From: Eric Auger To: eric.auger.pro@gmail.com, eric.auger@redhat.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, peter.maydell@linaro.org Date: Tue, 11 Jun 2019 16:28:21 +0200 Message-Id: <20190611142821.3874-3-eric.auger@redhat.com> In-Reply-To: <20190611142821.3874-1-eric.auger@redhat.com> References: <20190611142821.3874-1-eric.auger@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 11 Jun 2019 14:28:55 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH 2/2] hw/arm/smmuv3: Implement dummy replay 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: peterx@redhat.com Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" On ARM we currently do not support VFIO-PCI devices protected by the IOMMU. Any attempt to run such use case results in this kind of warning: "-device vfio-pci,host=0004:01:00.0,id=hostdev0,bus=pci.1,addr=0x0: warning: SMMUv3 does not support notification on MAP: device vfio-pci will not function properly". However this is just a warning and this should not prevent the guest from booting in a reasonable amount of time. This does not happen currently. This is due to the fact the VFIO vfio_listener_region_add() calls memory_region_iommu_replay(). As the SMMUv3 IOMMUMemoryRegionClass currently does not implement the replay() callback, the default memory_region_iommu_replay() implementation is used. This latter loops on the whole notifier's range (48b address space), translates each page and call the notifier on the resulting entry. This totally freezes the guest. The Intel IOMMU implements the replay() function which only notifies valid page table entries. In the looming SMMUv3 nested stage VFIO integration, there will be no need to replay() anything as there will not be any shadow page tables: the stage 1 page tables are owned by the guest. So let's implement a void replay() which satisfies both cases. Signed-off-by: Eric Auger --- hw/arm/smmuv3.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c index e2f07d2864..1f578365ef 100644 --- a/hw/arm/smmuv3.c +++ b/hw/arm/smmuv3.c @@ -1489,6 +1489,11 @@ static void smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu, } } +static inline void +smmuv3_replay(IOMMUMemoryRegion *iommu_mr, IOMMUNotifier *n) +{ +} + static void smmuv3_iommu_memory_region_class_init(ObjectClass *klass, void *data) { @@ -1496,6 +1501,7 @@ static void smmuv3_iommu_memory_region_class_init(ObjectClass *klass, imrc->translate = smmuv3_translate; imrc->notify_flag_changed = smmuv3_notify_flag_changed; + imrc->replay = smmuv3_replay; } static const TypeInfo smmuv3_type_info = {