From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750834AbdAXQw2 convert rfc822-to-8bit (ORCPT ); Tue, 24 Jan 2017 11:52:28 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:7889 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750707AbdAXQw0 (ORCPT ); Tue, 24 Jan 2017 11:52:26 -0500 From: Shameerali Kolothum Thodi To: Robin Murphy , Marc Zyngier , "mark.rutland@arm.com" , "will.deacon@arm.com" , "eric.auger@redhat.com" CC: "linux-arm-kernel@lists.infradead.org" , Linuxarm , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , John Garry , "Guohanjun (Hanjun Guo)" Subject: RE: [RFC 2/4] irqchip, gicv3-its:Workaround for HiSilicon erratum 161010801 Thread-Topic: [RFC 2/4] irqchip, gicv3-its:Workaround for HiSilicon erratum 161010801 Thread-Index: AQHSdkvITGaBOx/2fUac7S0g3wnXmKFHs3GAgAAKm8CAAAhigIAABEUggAAG1gCAAAOcgIAAAVXw Date: Tue, 24 Jan 2017 16:51:39 +0000 Message-ID: <5FC3163CFD30C246ABAA99954A238FA8174ACA05@lhreml504-mbs> References: <5886262C.6070108@huawei.com> <58875B0D.4080303@huawei.com> <5f303abc-209b-3828-ca8c-4ec0977f89ea@arm.com> <5FC3163CFD30C246ABAA99954A238FA8174AC552@lhreml504-mbs> <9764b04c-f610-ecca-e4ee-021d16371d7d@arm.com> <5FC3163CFD30C246ABAA99954A238FA8174AC5FC@lhreml504-mbs> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.177.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58878626.00F1,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6bed4fd810de35bc3cf3cbe0095f678b Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Robin Murphy [mailto:robin.murphy@arm.com] > Sent: Tuesday, January 24, 2017 4:43 PM > To: Marc Zyngier; Shameerali Kolothum Thodi; mark.rutland@arm.com; > will.deacon@arm.com; eric.auger@redhat.com > Cc: linux-arm-kernel@lists.infradead.org; Linuxarm; linux- > kernel@vger.kernel.org; devicetree@vger.kernel.org; John Garry; > Guohanjun (Hanjun Guo) > Subject: Re: [RFC 2/4] irqchip, gicv3-its:Workaround for HiSilicon > erratum 161010801 > > On 24/01/17 16:29, Marc Zyngier wrote: > > On 24/01/17 16:14, Shameerali Kolothum Thodi wrote: > >>>>>> Let's contemplate this for a moment. If we're on the affected > >>>>>> ITS, > >>>>> we're > >>>>>> using the physical address of the GITS_TRANSLATER register. What > >>>>>> guarantees that this is not going to conflict with an IOVA that > >>>>>> DMA > >>>>> is > >>>>>> going to use? From looking at these patches, my feeling is "not > >>>>> much". > >>>>>> > >>>>>> So if I'm right, you're opening the door to some interesting > >>>>>> memory corruption if the two regions ever intersect. > >>>>>> > >>>>>> Robin, what do you think? > >>>>> > >>>>> Yup. Unless the ITS physical address is actually reserved from > the > >>>>> IOVA domain, it's still free to be allocated for DMA mappings, > and > >>> if > >>>>> that ever happens then you'll get odd bits of data landing in the > >>> ITS > >>>>> instead of RAM, and maybe even locked-up devices or worse if the > >>>>> doorbell gives back decode errors on read attempts. It's > >>>>> essentially the exact same problem as we have with memory-mapped > >>>>> PCI windows, > >>> and > >>>>> needs to be solved in the same fashion, i.e. between the SMMU and > >>> the > >>>>> IOMMU-DMA code. > >>>> > >>>> Is this something that can incorporated in Eric's latest patch > >>> series[1]? > >>>> It does mentions reserved regions can be: > >>>> - directly mapped regions > >>>> - regions that cannot be iommu mapped (PCI host bridge windows, > >>>> ...) > >>>> - MSI regions (because they belong to another address space or > >>> because > >>>> they are not translated by the IOMMU and need special handling) > >>>> > >>>> Though I am not clear our case comes under "the MSI regions that > >>>> are not translated by the IOMMU and need special handling" or not. > >>> > >>> Well, given that in your case, the IOMMU never sees the MSI write, > >>> it definitely falls into the "not translated" category. > >>> > >>> As for handling it on top of Eric's series, that's probably the > most > >>> reasonable thing to do, which also means that none of this should > >>> appear in the ITS driver. Robin seems to have an idea on how to > >>> approach this. > >> > >> Ok. Thanks for that Marc/Robin. > >> > >> But I am not sure we can get away with ITS driver. Because current > >> vfio patch series[1] treats GICV3 ITS as irq safe and is setting > >> IRQ_DOMAIN_FLAG_MSI_REMAP in ITS driver. But this is not the case > >> with our ITS. > > > > The ITS itself is perfectly safe, as it does perform device isolation > > just fine (at least as far as I can tell from this bug description). > > > > There is two things we need to take care of: > > - When the device is used on the host, the hardwired MSI region must > > be excluded from the DMA IOVA allocator, and the > > iommu_dma_map_msi_msg() call becomes a NOP. > > - When the device is assigned to VFIO, the MSI region must be exposed > > to userspace through /sys so that it knows that the guest RAM cannot > > alias with this region (or face the corruption we've talked about > above). > > > > None of that actually involves the ITS. Eric's stuff has some of the > > initial infrastructure, but there is of course more to it. I'll let > > Robin chime in and correct me if I've missed something (very likely). > > That's pretty much it. Once Eric's patches for the iommu_resv_regions > interface have been merged, I'm planning to convert IOMMU-DMA over to > using those instead of the internal PCI-specific hook it currently has. > Then we would simply need the SMMU driver to expose this hardwired MSI > region where necessary so that IOMMU-DMA can directly insert 1:1 > iommu_dma_msi_page entries to cover it up-front in > iommu_dma_init_domain(). > Thanks for the details. Just wondering how this 1:1 map regions will be specified. I suppose this can be a DT property to SMMU driver. Is there anything available in ACPI table for this? Thanks, Shameer