> From: Raj, Ashok
> Sent: Saturday, September 8, 2018 1:43 AM
>
> On Fri, Sep 07, 2018 at 10:47:11AM +0800, Lu Baolu wrote:
> >
> > >>+
> > >>+ intel_pasid_clear_entry(dev, pasid);
> > >>+
> > >>+ if (!ecap_coherent(iommu->ecap)) {
> > >>+ pte = intel_pasid_get_entry(dev, pasid);
> > >>+
Hi Geert
Thank you for your feedback
> > -
> > commit ac6bbf0cdf4206c517ac9789814c23e372ebce4d
> > Author: Rob Herring
> > Date: Mon Jul 9 09:41:52 2018 -0600
> >
> > iommu: Remove IOMMU_OF_DECLARE
> >
> > Now that we use the driver
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: Wednesday, September 12, 2018 10:29 PM
> To: Nipun Gupta
> Cc: j...@8bytes.org; robin.mur...@arm.com; robh...@kernel.org;
> r...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com;
> gre...@linuxfoundat
On 2018/9/13 1:12, Robin Murphy wrote:
> On 12/09/18 17:57, Will Deacon wrote:
>> Hi all,
>>
>> On Wed, Aug 15, 2018 at 09:28:25AM +0800, Zhen Lei wrote:
>>> v4 -> v5:
>>> 1. change the type of global variable and struct member named "non_strict"
>>> from
>>> "int" to "bool".
>>> 2. cancel
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Thursday, September 13, 2018 1:54 AM
>
> On 12/09/2018 06:02, Lu Baolu wrote:
> > Hi,
> >
> > On 09/11/2018 12:23 AM, Jean-Philippe Brucker wrote:
> >> On 30/08/2018 05:09, Lu Baolu wrote:
> >>> +static int vfio_detach_au
> From: Jean-Philippe Brucker
> Sent: Thursday, September 13, 2018 1:54 AM
>
> On 12/09/2018 03:42, Lu Baolu wrote:
> > Hi,
> >
> > On 09/11/2018 12:22 AM, Jean-Philippe Brucker wrote:
> >> Hi,
> >>
> >> On 30/08/2018 05:09, Lu Baolu wrote:
> >>> Below APIs are introduced in the IOMMU glue for dev
On 12/09/2018 06:02, Lu Baolu wrote:
> Hi,
>
> On 09/11/2018 12:23 AM, Jean-Philippe Brucker wrote:
>> On 30/08/2018 05:09, Lu Baolu wrote:
>>> +static int vfio_detach_aux_domain(struct device *dev, void *data)
>>> +{
>>> + struct iommu_domain *domain = data;
>>> +
>>> + vfio_mdev_set_aux_doma
On 12/09/2018 03:42, Lu Baolu wrote:
> Hi,
>
> On 09/11/2018 12:22 AM, Jean-Philippe Brucker wrote:
>> Hi,
>>
>> On 30/08/2018 05:09, Lu Baolu wrote:
>>> Below APIs are introduced in the IOMMU glue for device drivers to use
>>> the finer granularity translation.
>>>
>>> * iommu_capable(IOMMU_CAP_A
On Thu, Aug 09, 2018 at 01:44:17PM -0600, Alex Williamson wrote:
> On Thu, 9 Aug 2018 12:37:06 -0700
> Ashok Raj wrote:
>
> > PCI_INTERRUPT_PIN should always read 0 for SRIOV Virtual Functions.
> >
> > Some SRIOV devices have some bugs in RTL and VF's end up reading 1
> > instead of 0 for the
On 12/09/18 17:57, Will Deacon wrote:
Hi all,
On Wed, Aug 15, 2018 at 09:28:25AM +0800, Zhen Lei wrote:
v4 -> v5:
1. change the type of global variable and struct member named "non_strict" from
"int" to "bool".
2. cancel the unnecessary parameter "strict" of __arm_lpae_unmap which was added
Hi Nipun,
On Mon, Sep 10, 2018 at 07:19:14PM +0530, Nipun Gupta wrote:
> This patchset defines IOMMU DT binding for fsl-mc bus and adds
> support in SMMU for fsl-mc bus.
>
> These patches
> - Define property 'iommu-map' for fsl-mc bus (patch 1)
> - Integrates the fsl-mc bus with the SMMU usin
Hi all,
On Wed, Aug 15, 2018 at 09:28:25AM +0800, Zhen Lei wrote:
> v4 -> v5:
> 1. change the type of global variable and struct member named "non_strict"
> from
>"int" to "bool".
> 2. cancel the unnecessary parameter "strict" of __arm_lpae_unmap which was
> added
>in v4.
> 3. change boo
Having of_reserved_mem_device_init() forcibly reconfigure DMA for all
callers, potentially overriding the work done by a bus-specific
.dma_configure method earlier, is at best a bad idea and at worst
actively harmful. If drivers really need virtual devices to own
dma-coherent memory, they should ex
On Tue, Sep 11, 2018 at 11:43:47AM +0200, Geert Uytterhoeven wrote:
> So it seems the audio DMAC is deferred a second time, before the iommu driver
> probed.
Shouldn't there be at least one more round of deferred probe triggers
after the IOMMU probes?
signature.asc
Description: PGP signature
__
While iommu_get_domain_for_dev() is the robust way for arbitrary IOMMU
API callers to retrieve the domain pointer, for DMA ops domains it
doesn't scale well for large systems and multi-queue devices, since the
momentary refcount adjustment will lead to exclusive cacheline contention
when multiple C
Whilst the symmetry of deferring to the existing sync callback in
__iommu_map_page() is nice, taking a round-trip through
iommu_iova_to_phys() is a pretty heavyweight way to get an address we
can trivially compute from the page we already have. Tweaking it to just
perform the cache maintenance dire
Most parts of iommu-dma already assume they are operating on a default
domain set up by iommu_dma_init_domain(), and can be converted straight
over to avoid the refcounting bottleneck. MSI page mappings may be in
an unmanaged domain with an explicit MSI-only cookie, so retain the
non-specific looku
John raised the issue[1] that we have some unnecessary refcount contention
in the DMA ops path which shows scalability problems now that we have more
real high-performance hardware using iommu-dma. The x86 IOMMU drivers are
sidestepping this by stashing domain references in archdata, but since
that
Am 12.09.2018 um 14:40 schrieb Jean-Philippe Brucker:
On 08/09/2018 08:29, Christian König wrote:
Yes, exactly. I just need a PASID which is never used by the OS for a
process and we can easily give that back when the last FD reference is
closed.
Alright, iommu-sva can get its PASID from this e
On 08/09/2018 08:29, Christian König wrote:
> Yes, exactly. I just need a PASID which is never used by the OS for a
> process and we can easily give that back when the last FD reference is
> closed.
Alright, iommu-sva can get its PASID from this external allocator as
well, as long as it has an i
20 matches
Mail list logo
