Hi Tomasz,
On 2020-07-20 6:10 a.m., Tomasz Figa wrote:
> On Sat, Jul 11, 2020 at 8:17 PM Jonathan Bakker wrote:
>>
>> Hi Tomasz,
>>
>> On 2020-07-07 11:44 a.m., Tomasz Figa wrote:
>>> Hi Jonathan,
>>>
>>> On Sat, Apr 25, 2020 at 07:26:49PM -0700, Jonathan Bakker wrote:
media_pipeline_stop
The pull request you sent on Fri, 24 Jul 2020 20:26:44 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fix-v5.8-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5a0b8af0719fd0710d9d1a9ad83b7fbdf4bfca66
Thank you!
--
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
NOTE: ChristophH wanted the dma_set_offset_range() function
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
The default domain type of an iommu group can be changed by writing to
"/sys/kernel/iommu_groups//type" file. Hence, document it's usage
and more importantly spell out its limitations.
Cc: Christoph Hellwig
Cc: Joerg Roedel
Cc: Ashok Raj
Cc: Will Deacon
Cc: Lu Baolu
Cc: Sohil Mehta
Cc:
"/sys/kernel/iommu_groups//type" file could be read to find out the
default domain type of an iommu group. The default domain of an iommu group
doesn't change after booting and hence could be read directly. But,
after addding support to dynamically change iommu group default domain, the
above
Presently, the default domain of an iommu group is allocated during boot
time and it cannot be changed later. So, the device would typically be
either in identity (also known as pass_through) mode or the device would be
in DMA mode as long as the machine is up and running. There is no way to
Presently, the default domain of an iommu group is allocated during boot time
and it cannot be changed later. So, the device would typically be either in
identity (pass_through) mode or the device would be in DMA mode as long as the
system is up and running. There is no way to change the default
Hi Linus,
The following changes since commit ba47d845d715a010f7b51f6f89bae32845e6acb7:
Linux 5.8-rc6 (2020-07-19 15:41:18 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fix-v5.8-rc6
for you to fetch changes up to
On Fri, Jul 24, 2020 at 09:49:17PM +0530, Amit Pundir wrote:
> On Fri, 24 Jul 2020 at 19:11, Christoph Hellwig wrote:
> >
> > Yes, the iommu is an interesting case, and the current code is
> > wrong for that. Can you try the patch below? It contains a modified
> > version of Nicolas' patch to
On Fri, 24 Jul 2020 at 19:11, Christoph Hellwig wrote:
>
> Yes, the iommu is an interesting case, and the current code is
> wrong for that. Can you try the patch below? It contains a modified
> version of Nicolas' patch to try CMA again for the expansion and a new
> (for now hackish) way to not
On Thu, Jul 23, 2020 at 03:37:29PM -0700, Ashok Raj wrote:
> PASID and PRI capabilities are only enumerated in PF devices. VF devices
> do not enumerate these capabilites. IOMMU drivers also need to enumerate
> them before enabling features in the IOMMU. Extending the same support as
> PASID
Yes, the iommu is an interesting case, and the current code is
wrong for that. Can you try the patch below? It contains a modified
version of Nicolas' patch to try CMA again for the expansion and a new
(for now hackish) way to not apply the addressability check for dma-iommu
allocations.
diff
On Thu, Jul 23, 2020 at 09:34:37AM +0800, Lu Baolu wrote:
> The VT-d spec requires (10.4.4 Global Command Register, TE field) that:
>
> Hardware implementations supporting DMA draining must drain any in-flight
> DMA read/write requests queued within the Root-Complex before completing
> the
On Thu, Jul 23, 2020 at 07:36:52PM +0800, Baolin Wang wrote:
> Thanks Will. Joerg, could you apply this 2 patches if no objection from
> your side? Thanks.
Applied both, thanks. Modified the first patch because another patch
already made __iommu_map static.
Hi Will,
On Fri, Jul 24, 2020 at 12:51:09PM +0100, Will Deacon wrote:
> Sure, that makes sense to me: I've included a diff below in case anybody
> has comments. I've tackled it slightly differently to how the intel and
> amd drivers are handled, since we have a header file (arm-smmu.h) which
> is
Hi Joerg,
On Wed, Jul 22, 2020 at 03:33:23PM +0200, Joerg Roedel wrote:
> On Tue, Jul 21, 2020 at 09:03:53AM +0100, Will Deacon wrote:
> > Please pull these Arm SMMU driver updates for 5.9. Summary is in the tag,
> > but the main thing is support for two new SoC integrations, one of which
> > is
On Fri, 24 Jul 2020 at 15:06, Nicolas Saenz Julienne
wrote:
>
> Hi Amit,
>
> On Thu, 2020-07-23 at 10:44 +0530, Amit Pundir wrote:
> > Hi Nicolas,
> >
> > Sorry I got stuck on other things yesterday.
>
> No worries :)
>
> > On Tue, 21 Jul 2020 at 21:57, Nicolas Saenz Julienne
>
> [...]
>
> > >
>
Hi Amit,
On Thu, 2020-07-23 at 10:44 +0530, Amit Pundir wrote:
> Hi Nicolas,
>
> Sorry I got stuck on other things yesterday.
No worries :)
> On Tue, 21 Jul 2020 at 21:57, Nicolas Saenz Julienne
[...]
> >
> > Let's get a bigger hammer, I'm just looking for clues here. Can you
> > apply this
Hi Joerg,
On 2020/7/24 16:55, Joerg Roedel wrote:
On Fri, Jul 24, 2020 at 09:49:13AM +0800, Lu Baolu wrote:
Below patches have been piled up for v5.9. It includes:
- Misc tweaks and fixes for vSVA
- Report/response page request events
- Cleanups
Can you please consider them for
On Fri, Jul 24, 2020 at 09:49:13AM +0800, Lu Baolu wrote:
> Below patches have been piled up for v5.9. It includes:
>
> - Misc tweaks and fixes for vSVA
> - Report/response page request events
> - Cleanups
>
> Can you please consider them for iommu/next?
Applied, thanks Baolu.
For the next
On Thu, Jul 23, 2020 at 03:37:29PM -0700, Ashok Raj wrote:
> PASID and PRI capabilities are only enumerated in PF devices. VF devices
> do not enumerate these capabilites. IOMMU drivers also need to enumerate
> them before enabling features in the IOMMU. Extending the same support as
> PASID
22 matches
Mail list logo
