Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941152AbcLVNCt (ORCPT ); Thu, 22 Dec 2016 08:02:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51556 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753525AbcLVNCr (ORCPT ); Thu, 22 Dec 2016 08:02:47 -0500 Subject: Re: [RFC v4 15/16] vfio/type1: Check MSI remapping at irq domain level To: Diana Madalina Craciun , "eric.auger.pro@gmail.com" , "christoffer.dall@linaro.org" , "marc.zyngier@arm.com" , "robin.murphy@arm.com" , "alex.williamson@redhat.com" , "will.deacon@arm.com" , "joro@8bytes.org" , "tglx@linutronix.de" , "jason@lakedaemon.net" , "linux-arm-kernel@lists.infradead.org" References: <1481661034-3088-1-git-send-email-eric.auger@redhat.com> <1481661034-3088-16-git-send-email-eric.auger@redhat.com> Cc: "kvm@vger.kernel.org" , "drjones@redhat.com" , "linux-kernel@vger.kernel.org" , "pranav.sawargaonkar@gmail.com" , "iommu@lists.linux-foundation.org" , "punit.agrawal@arm.com" , "gpkulkarni@gmail.com" , "shankerd@codeaurora.org" , Bharat Bhushan From: Auger Eric Message-ID: <3ead0cc1-7798-3e39-da56-c18a5989c00c@redhat.com> Date: Thu, 22 Dec 2016 14:02:40 +0100 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.32]); Thu, 22 Dec 2016 13:02:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2825 Lines: 80 Hi Diana, On 22/12/2016 13:41, Diana Madalina Craciun wrote: > Hi Eric, > > On 12/13/2016 10:32 PM, Eric Auger wrote: >> In case the IOMMU does not bypass MSI transactions (typical >> case on ARM), we check all MSI controllers are IRQ remapping >> capable. If not the IRQ assignment may be unsafe. >> >> At this stage the arm-smmu-(v3) still advertise the >> IOMMU_CAP_INTR_REMAP capability at IOMMU level. This will be >> removed in subsequent patches. >> >> Signed-off-by: Eric Auger >> --- >> drivers/vfio/vfio_iommu_type1.c | 9 ++++++--- >> 1 file changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c >> index d07fe73..a05648b 100644 >> --- a/drivers/vfio/vfio_iommu_type1.c >> +++ b/drivers/vfio/vfio_iommu_type1.c >> @@ -37,6 +37,7 @@ >> #include >> #include >> #include >> +#include >> >> #define DRIVER_VERSION "0.2" >> #define DRIVER_AUTHOR "Alex Williamson " >> @@ -765,7 +766,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data, >> struct vfio_domain *domain, *d; >> struct bus_type *bus = NULL; >> int ret; >> - bool resv_msi; >> + bool resv_msi, msi_remap; >> phys_addr_t resv_msi_base; >> >> mutex_lock(&iommu->lock); >> @@ -818,8 +819,10 @@ static int vfio_iommu_type1_attach_group(void *iommu_data, >> INIT_LIST_HEAD(&domain->group_list); >> list_add(&group->next, &domain->group_list); >> >> - if (!allow_unsafe_interrupts && >> - !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) { >> + msi_remap = resv_msi ? 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", >> __func__); >> ret = -EPERM; > > I tested your v4.9-reserved-v4 branch on a ITS capable hardware (NXP > LS2080), so I did not set allow_unsafe_interrupts. It fails here > complaining that the there is no interrupt remapping support. The > irq_domain_check_msi_remap function returns false as none of the checked > domains has the IRQ_DOMAIN_FLAG_MSI_REMAP flag set. I think the reason > is that the flags are not propagated through the domain hierarchy when > the domain is created. Hum OK. Please apologize for the inconvenience, all the more so this is the second time you report the same issue for different cause :-( At the moment I can't test on a GICv3 ITS based system. I will try to fix that though. I would like to get the confirmation introducing this flag is the right direction though. Thanks Eric > > Thanks, > > Diana > > >