> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Tuesday, February 11, 2020 5:46 PM
> To: Leo Li
> Cc: Joerg Roedel ; Will Deacon ;
> Robin Murphy ; iommu@lists.linux-
> foundation.org; linux-ker...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject:
On Wed, Feb 12, 2020 at 12:03 AM Derrick, Jonathan
wrote:
> On Tue, 2020-02-11 at 17:13 +0800, Daniel Drake wrote:
> > The PCI devices handled by intel-iommu may have a DMA requester on
> > another bus, such as VMD subdevices needing to use the VMD endpoint.
> >
> > The real DMA device is now used
Commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module")
introduced a side effect that changed the module name from arm-smmu to
arm-smmu-mod. This breaks the users of kernel parameters for the driver
(e.g. arm-smmu.disable_bypass). This patch changes the module name back
to be consisten
On Tue, Feb 11, 2020 at 5:47 PM Russell King - ARM Linux admin
wrote:
>
> On Tue, Feb 11, 2020 at 05:36:55PM -0600, Li Yang wrote:
> > Since commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module"),
> > there is a side effect that the module name is changed from arm-smmu to
> > arm-smmu-
On 11.02.2020 23:00, Chuck Lever wrote:
Hi Andre, thanks for trying this out.
On Feb 11, 2020, at 3:50 PM, Andre Tomt wrote:
On 11.02.2020 20:58, Chuck Lever wrote:
The @nents value that was passed to ib_dma_map_sg() has to be passed
to the matching ib_dma_unmap_sg() call. If ib_dma_map_sg()
On Tue, Feb 11, 2020 at 05:36:55PM -0600, Li Yang wrote:
> Since commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module"),
> there is a side effect that the module name is changed from arm-smmu to
> arm-smmu-mod. So the kernel parameter for disable_bypass need to be
> changed too. Fix t
Since commit cd221bd24ff5 ("iommu/arm-smmu: Allow building as a module"),
there is a side effect that the module name is changed from arm-smmu to
arm-smmu-mod. So the kernel parameter for disable_bypass need to be
changed too. Fix the Kconfig help and error message to the correct
parameter name.
Hi Andre, thanks for trying this out.
> On Feb 11, 2020, at 3:50 PM, Andre Tomt wrote:
>
> On 11.02.2020 20:58, Chuck Lever wrote:
>> The @nents value that was passed to ib_dma_map_sg() has to be passed
>> to the matching ib_dma_unmap_sg() call. If ib_dma_map_sg() choses to
>> concatenate sg ent
On 11.02.2020 20:58, Chuck Lever wrote:
The @nents value that was passed to ib_dma_map_sg() has to be passed
to the matching ib_dma_unmap_sg() call. If ib_dma_map_sg() choses to
concatenate sg entries, it will return a different nents value than
it was passed.
The bug was exposed by recent chang
The @nents value that was passed to ib_dma_map_sg() has to be passed
to the matching ib_dma_unmap_sg() call. If ib_dma_map_sg() choses to
concatenate sg entries, it will return a different nents value than
it was passed.
The bug was exposed by recent changes to the AMD IOMMU driver.
Reported-by:
On 11.02.2020 17:36, Robin Murphy wrote:
On 11/02/2020 4:03 pm, Chuck Lever wrote:
Robin, your explanation makes sense to me. I can post a fix for this
imbalance later today for Andre to try.
FWIW here's a quick hack which *should* suppress the concatenation
behaviour - if it makes Andre's sy
> On Feb 11, 2020, at 11:36 AM, Robin Murphy wrote:
>
> On 11/02/2020 4:03 pm, Chuck Lever wrote:
>>> On Feb 11, 2020, at 10:32 AM, Robin Murphy wrote:
>>>
>>> On 11/02/2020 3:24 pm, Chuck Lever wrote:
> On Feb 11, 2020, at 10:12 AM, Robin Murphy wrote:
>
> On 11/02/2020 1:48 p
On 11/02/2020 4:03 pm, Chuck Lever wrote:
On Feb 11, 2020, at 10:32 AM, Robin Murphy wrote:
On 11/02/2020 3:24 pm, Chuck Lever wrote:
On Feb 11, 2020, at 10:12 AM, Robin Murphy wrote:
On 11/02/2020 1:48 pm, Chuck Lever wrote:
Andre-
Thank you for the detailed report!
Tom-
There is a rich
> On Feb 11, 2020, at 10:32 AM, Robin Murphy wrote:
>
> On 11/02/2020 3:24 pm, Chuck Lever wrote:
>>> On Feb 11, 2020, at 10:12 AM, Robin Murphy wrote:
>>>
>>> On 11/02/2020 1:48 pm, Chuck Lever wrote:
Andre-
Thank you for the detailed report!
Tom-
There is a rich set of
Hi Daniel
On Tue, 2020-02-11 at 17:13 +0800, Daniel Drake wrote:
> The PCI devices handled by intel-iommu may have a DMA requester on
> another bus, such as VMD subdevices needing to use the VMD endpoint.
>
> The real DMA device is now used for the DMA mapping, but one case was
> missed earlier,
On 11/02/2020 3:24 pm, Chuck Lever wrote:
On Feb 11, 2020, at 10:12 AM, Robin Murphy wrote:
On 11/02/2020 1:48 pm, Chuck Lever wrote:
Andre-
Thank you for the detailed report!
Tom-
There is a rich set of trace points available in the RPC/RDMA implementation in
5.4/5.5, fwiw.
Please keep me
> On Feb 11, 2020, at 10:12 AM, Robin Murphy wrote:
>
> On 11/02/2020 1:48 pm, Chuck Lever wrote:
>> Andre-
>> Thank you for the detailed report!
>> Tom-
>> There is a rich set of trace points available in the RPC/RDMA implementation
>> in 5.4/5.5, fwiw.
>> Please keep me in the loop, let me
On 11/02/2020 1:48 pm, Chuck Lever wrote:
Andre-
Thank you for the detailed report!
Tom-
There is a rich set of trace points available in the RPC/RDMA implementation in
5.4/5.5, fwiw.
Please keep me in the loop, let me know if there is anything I can do to help.
One aspect that may be worth
Andre-
Thank you for the detailed report!
Tom-
There is a rich set of trace points available in the RPC/RDMA implementation in
5.4/5.5, fwiw.
Please keep me in the loop, let me know if there is anything I can do to help.
> On Feb 11, 2020, at 2:25 AM, Joerg Roedel wrote:
>
> Adding Tom's ne
Hi Robin,
On Mon, Jan 27, 2020 at 07:01:02PM +, Robin Murphy wrote:
> > > > +static void sun50i_iommu_domain_free(struct iommu_domain *domain)
> > > > +{
> > > > + struct sun50i_iommu_domain *sun50i_domain =
> > > > to_sun50i_domain(domain);
> > > > + struct sun50i_iommu *iommu =
The PCI devices handled by intel-iommu may have a DMA requester on
another bus, such as VMD subdevices needing to use the VMD endpoint.
The real DMA device is now used for the DMA mapping, but one case was
missed earlier, when allocating memory through (e.g.) intel_map_page().
Confusion ensues if
On Sat, Feb 8, 2020 at 2:30 PM Lu Baolu wrote:
> > The devices under segment 1 are fake devices produced by
> > intel-nvme-remap mentioned here https://lkml.org/lkml/2020/2/5/139
>
> Has this series been accepted?
Sadly not - we didn't find any consensus on the right approach, and
further convers
VMD subdevices are created with a PCI domain ID of 0x1 or
higher.
These subdevices are also handled like all other PCI devices by
dmar_pci_bus_notifier().
However, when dmar_alloc_pci_notify_info() take records of such devices,
it will truncate the domain ID to a u16 value (in info->seg).
The
On 2020/2/11 上午7:37, Greg Kroah-Hartman wrote:
On Wed, Jan 15, 2020 at 10:12:46PM +0800, Zhangfei Gao wrote:
From: Kenneth Lee
Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerato
24 matches
Mail list logo
