From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753986AbdG3Kje (ORCPT ); Sun, 30 Jul 2017 06:39:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51304 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750805AbdG3Kjd (ORCPT ); Sun, 30 Jul 2017 06:39:33 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9D464F7A06 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eric.auger@redhat.com From: Auger Eric Subject: Re: [PATCH 1/2] vfio/type1: Cope with hardware MSI reserved regions To: Robin Murphy , alex.williamson@redhat.com References: Cc: kvm@vger.kernel.org, marc.zyngier@arm.com, linux-kernel@vger.kernel.org, shameerali.kolothum.thodi@huawei.com, linux-arm-kernel@lists.infradead.org Message-ID: <263da1c2-1a76-020a-62d8-e65b2256030f@redhat.com> Date: Sun, 30 Jul 2017 12:39:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Sun, 30 Jul 2017 10:39:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robin, On 27/07/2017 16:54, Robin Murphy wrote: > For ARM-based systems with a GICv3 ITS to provide interrupt isolation, > but hardware limitations which are worked around by having MSIs bypass > SMMU translation (e.g. HiSilicon Hip06/Hip07), VFIO neglects to check > for the IRQ_DOMAIN_FLAG_MSI_REMAP capability, (and thus erroneously > demands unsafe_interrupts) if a software-managed MSI region is absent. > > Fix this by always checking for isolation capability at both the IRQ > domain and IOMMU domain levels, rather than predicating that on whether > MSIs require an IOMMU mapping (which was always slightly tenuous logic). > > Signed-off-by: Robin Murphy Reviewed-by: Eric Auger Thanks Eric > --- > drivers/vfio/vfio_iommu_type1.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c > index 8549cb111627..2328be628f21 100644 > --- a/drivers/vfio/vfio_iommu_type1.c > +++ b/drivers/vfio/vfio_iommu_type1.c > @@ -1265,8 +1265,8 @@ static int vfio_iommu_type1_attach_group(void *iommu_data, > INIT_LIST_HEAD(&domain->group_list); > list_add(&group->next, &domain->group_list); > > - msi_remap = resv_msi ? irq_domain_check_msi_remap() : > - iommu_capable(bus, IOMMU_CAP_INTR_REMAP); > + msi_remap = irq_domain_check_msi_remap() || > + iommu_capable(bus, IOMMU_CAP_INTR_REMAP); > > if (!allow_unsafe_interrupts && !msi_remap) { > pr_warn("%s: No interrupt remapping support. Use the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n", >