From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Shanker Donthineni <shankerd@qti.qualcomm.com>,
kvm@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
Sinan Kaya <okaya@qti.qualcomm.com>,
Will Deacon <will.deacon@arm.com>,
iommu@lists.linux-foundation.org,
Harv Abdulhamid <harba@qti.qualcomm.com>,
Alex Williamson <alex.williamson@redhat.com>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Robin Murphy <robin.murphy@arm.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org,
Nate Watterson <nwatters@qti.qualcomm.com>
Subject: Re: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task
Date: Fri, 24 Mar 2017 19:08:47 +0000 [thread overview]
Message-ID: <7386120a-2848-059f-4de0-7888a2698923@arm.com> (raw)
In-Reply-To: <20170324110045.GM7266@8bytes.org>
On 24/03/17 11:00, Joerg Roedel wrote:
> On Thu, Mar 23, 2017 at 05:03:46PM +0000, Jean-Philippe Brucker wrote:
>> On 23/03/17 16:52, Joerg Roedel wrote:
>>> Thanks for that, I have a closer look. Is that stopper packet visible to
>>> software (e.g. is an entry created in the queue)?
>>
>> As far as I understand, it should be added to the queue like a normal PPR,
>> and software should check the R/W/L flags combination. For SMMU at least,
>> it is the same. The only difference is that when the PRI queue overflows,
>> the SMMU would discard a Stop Marker instead of sending an automated
>> response to the device (as it would do with others PPR that have the L
>> flag.) Software shouldn't send a response to a Stop Marker either.
>
> The document you posted is an addition to the spec, so we can't rely on
> a stop marker being sent by a device when it shuts down a context.
> Current AMD GPUs don't send one, afaik.
Fair enough, though on the SMMU side we still don't know which shutdown
model hardware vendors are more likely to choose. Devices could use the
stop marker and never wait for completion of PPRs. In that case context
shutdown would only have to make sure that PPRs are outside the PCI
network, return immediately and allow the device driver to call unbind().
So to be on the safe side I think I will by default assume that PPRs are
in flight during unbind, and drain both software and hardware queue to
ensure we catch them all.
As an optimization, we can later add ways for device drivers or firmware
to inform the IOMMU which PASID shutdown model is implemented (maybe a
callback in svm_ops?), in which case we wouldn't have to flush the queue
and if necessary, we can wait for a stop marker before throwing away a PASID.
Thanks,
Jean-Philippe
> I think the best we can do is shutting down processing for this PASID
> when and inform the device driver, when we receive a stop marker. An
> additional, optional call-back would do the job.
>
>
>
> Joerg
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Harv Abdulhamid <harba@qti.qualcomm.com>,
Will Deacon <will.deacon@arm.com>,
Shanker Donthineni <shankerd@qti.qualcomm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Sinan Kaya <okaya@qti.qualcomm.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Robin Murphy <robin.murphy@arm.com>,
Nate Watterson <nwatters@qti.qualcomm.com>,
Alex Williamson <alex.williamson@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
iommu@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task
Date: Fri, 24 Mar 2017 19:08:47 +0000 [thread overview]
Message-ID: <7386120a-2848-059f-4de0-7888a2698923@arm.com> (raw)
In-Reply-To: <20170324110045.GM7266@8bytes.org>
On 24/03/17 11:00, Joerg Roedel wrote:
> On Thu, Mar 23, 2017 at 05:03:46PM +0000, Jean-Philippe Brucker wrote:
>> On 23/03/17 16:52, Joerg Roedel wrote:
>>> Thanks for that, I have a closer look. Is that stopper packet visible to
>>> software (e.g. is an entry created in the queue)?
>>
>> As far as I understand, it should be added to the queue like a normal PPR,
>> and software should check the R/W/L flags combination. For SMMU at least,
>> it is the same. The only difference is that when the PRI queue overflows,
>> the SMMU would discard a Stop Marker instead of sending an automated
>> response to the device (as it would do with others PPR that have the L
>> flag.) Software shouldn't send a response to a Stop Marker either.
>
> The document you posted is an addition to the spec, so we can't rely on
> a stop marker being sent by a device when it shuts down a context.
> Current AMD GPUs don't send one, afaik.
Fair enough, though on the SMMU side we still don't know which shutdown
model hardware vendors are more likely to choose. Devices could use the
stop marker and never wait for completion of PPRs. In that case context
shutdown would only have to make sure that PPRs are outside the PCI
network, return immediately and allow the device driver to call unbind().
So to be on the safe side I think I will by default assume that PPRs are
in flight during unbind, and drain both software and hardware queue to
ensure we catch them all.
As an optimization, we can later add ways for device drivers or firmware
to inform the IOMMU which PASID shutdown model is implemented (maybe a
callback in svm_ops?), in which case we wouldn't have to flush the queue
and if necessary, we can wait for a stop marker before throwing away a PASID.
Thanks,
Jean-Philippe
> I think the best we can do is shutting down processing for this PASID
> when and inform the device driver, when we receive a stop marker. An
> additional, optional call-back would do the job.
>
>
>
> Joerg
>
WARNING: multiple messages have this Message-ID (diff)
From: jean-philippe.brucker@arm.com (Jean-Philippe Brucker)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task
Date: Fri, 24 Mar 2017 19:08:47 +0000 [thread overview]
Message-ID: <7386120a-2848-059f-4de0-7888a2698923@arm.com> (raw)
In-Reply-To: <20170324110045.GM7266@8bytes.org>
On 24/03/17 11:00, Joerg Roedel wrote:
> On Thu, Mar 23, 2017 at 05:03:46PM +0000, Jean-Philippe Brucker wrote:
>> On 23/03/17 16:52, Joerg Roedel wrote:
>>> Thanks for that, I have a closer look. Is that stopper packet visible to
>>> software (e.g. is an entry created in the queue)?
>>
>> As far as I understand, it should be added to the queue like a normal PPR,
>> and software should check the R/W/L flags combination. For SMMU at least,
>> it is the same. The only difference is that when the PRI queue overflows,
>> the SMMU would discard a Stop Marker instead of sending an automated
>> response to the device (as it would do with others PPR that have the L
>> flag.) Software shouldn't send a response to a Stop Marker either.
>
> The document you posted is an addition to the spec, so we can't rely on
> a stop marker being sent by a device when it shuts down a context.
> Current AMD GPUs don't send one, afaik.
Fair enough, though on the SMMU side we still don't know which shutdown
model hardware vendors are more likely to choose. Devices could use the
stop marker and never wait for completion of PPRs. In that case context
shutdown would only have to make sure that PPRs are outside the PCI
network, return immediately and allow the device driver to call unbind().
So to be on the safe side I think I will by default assume that PPRs are
in flight during unbind, and drain both software and hardware queue to
ensure we catch them all.
As an optimization, we can later add ways for device drivers or firmware
to inform the IOMMU which PASID shutdown model is implemented (maybe a
callback in svm_ops?), in which case we wouldn't have to flush the queue
and if necessary, we can wait for a stop marker before throwing away a PASID.
Thanks,
Jean-Philippe
> I think the best we can do is shutting down processing for this PASID
> when and inform the device driver, when we receive a stop marker. An
> additional, optional call-back would do the job.
>
>
>
> Joerg
>
next prev parent reply other threads:[~2017-03-24 19:08 UTC|newest]
Thread overview: 314+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-27 19:54 [RFC PATCH 00/30] Add PCIe SVM support to ARM SMMUv3 Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 01/30] iommu/arm-smmu-v3: Link groups and devices Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-03-27 12:18 ` Robin Murphy
2017-03-27 12:18 ` Robin Murphy
2017-03-27 12:18 ` Robin Murphy
2017-04-10 11:02 ` Jean-Philippe Brucker
2017-04-10 11:02 ` Jean-Philippe Brucker
2017-04-10 11:02 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 02/30] iommu/arm-smmu-v3: Link groups and domains Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 03/30] PCI: Move ATS declarations outside of CONFIG_PCI Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-03-03 21:09 ` Bjorn Helgaas
2017-03-03 21:09 ` Bjorn Helgaas
2017-03-03 21:09 ` Bjorn Helgaas
2017-03-06 11:29 ` Jean-Philippe Brucker
2017-03-06 11:29 ` Jean-Philippe Brucker
2017-03-06 11:29 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 04/30] iommu/arm-smmu-v3: Add support for PCI ATS Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-03-01 19:24 ` Sinan Kaya
2017-03-01 19:24 ` Sinan Kaya
2017-03-01 19:24 ` Sinan Kaya
2017-03-02 10:51 ` Jean-Philippe Brucker
2017-03-02 10:51 ` Jean-Philippe Brucker
2017-03-02 10:51 ` Jean-Philippe Brucker
2017-03-02 13:11 ` okaya
2017-03-02 13:11 ` okaya at codeaurora.org
2017-03-02 13:11 ` okaya-sgV2jX0FEOL9JmXXK+q4OQ
2017-03-08 15:26 ` Sinan Kaya
2017-03-08 15:26 ` Sinan Kaya
2017-03-08 15:26 ` Sinan Kaya
2017-03-21 19:38 ` Jean-Philippe Brucker
2017-03-21 19:38 ` Jean-Philippe Brucker
2017-03-21 19:38 ` Jean-Philippe Brucker
2017-04-03 8:34 ` Sunil Kovvuri
2017-04-03 8:34 ` Sunil Kovvuri
2017-04-03 8:34 ` Sunil Kovvuri
2017-04-03 10:14 ` Jean-Philippe Brucker
2017-04-03 10:14 ` Jean-Philippe Brucker
2017-04-03 10:14 ` Jean-Philippe Brucker
2017-04-03 11:42 ` Sunil Kovvuri
2017-04-03 11:42 ` Sunil Kovvuri
2017-04-03 11:42 ` Sunil Kovvuri
2017-04-03 11:56 ` Jean-Philippe Brucker
2017-04-03 11:56 ` Jean-Philippe Brucker
2017-04-03 11:56 ` Jean-Philippe Brucker
2017-05-10 12:54 ` Tomasz Nowicki
2017-05-10 12:54 ` Tomasz Nowicki
2017-05-10 12:54 ` Tomasz Nowicki
2017-05-10 13:35 ` Jean-Philippe Brucker
2017-05-10 13:35 ` Jean-Philippe Brucker
2017-05-10 13:35 ` Jean-Philippe Brucker
2017-05-23 8:41 ` Leizhen (ThunderTown)
2017-05-23 8:41 ` Leizhen (ThunderTown)
2017-05-23 8:41 ` Leizhen (ThunderTown)
2017-05-23 8:41 ` Leizhen (ThunderTown)
2017-05-23 11:21 ` Jean-Philippe Brucker
2017-05-23 11:21 ` Jean-Philippe Brucker
2017-05-23 11:21 ` Jean-Philippe Brucker
2017-05-25 18:27 ` Roy Franz (Cavium)
2017-05-25 18:27 ` Roy Franz (Cavium)
2017-05-25 18:27 ` Roy Franz (Cavium)
2017-02-27 19:54 ` [RFC PATCH 05/30] iommu/arm-smmu-v3: Disable tagged pointers when ATS is in use Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-05-22 6:27 ` Leizhen (ThunderTown)
2017-05-22 6:27 ` Leizhen (ThunderTown)
2017-05-22 6:27 ` Leizhen (ThunderTown)
2017-05-22 6:27 ` Leizhen (ThunderTown)
2017-05-22 14:02 ` Jean-Philippe Brucker
2017-05-22 14:02 ` Jean-Philippe Brucker
2017-05-22 14:02 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 06/30] iommu/arm-smmu-v3: Add support for Substream IDs Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 07/30] iommu/arm-smmu-v3: Add second level of context descriptor table Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-05-15 12:47 ` Tomasz Nowicki
2017-05-15 12:47 ` Tomasz Nowicki
2017-05-15 12:47 ` Tomasz Nowicki
2017-05-15 13:57 ` Jean-Philippe Brucker
2017-05-15 13:57 ` Jean-Philippe Brucker
2017-05-15 13:57 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 08/30] iommu/arm-smmu-v3: Add support for VHE Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 09/30] iommu/arm-smmu-v3: Support broadcast TLB maintenance Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 10/30] iommu/arm-smmu-v3: Add task contexts Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 11/30] arm64: mm: Pin down ASIDs for sharing contexts with devices Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 12/30] iommu/arm-smmu-v3: Keep track of process address spaces Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 13/30] iommu/io-pgtable-arm: Factor out ARM LPAE register defines Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 14/30] iommu/arm-smmu-v3: Share process page tables Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 15/30] iommu/arm-smmu-v3: Steal private ASID from a domain Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 16/30] iommu/arm-smmu-v3: Use shared ASID set Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 17/30] iommu/arm-smmu-v3: Add SVM feature checking Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 18/30] PCI: Make "PRG Response PASID Required" handling common Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-03-03 21:11 ` Bjorn Helgaas
2017-03-03 21:11 ` Bjorn Helgaas
2017-03-03 21:11 ` Bjorn Helgaas
2017-03-06 11:31 ` Jean-Philippe Brucker
2017-03-06 11:31 ` Jean-Philippe Brucker
2017-03-06 11:31 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 19/30] PCI: Cache PRI and PASID bits in pci_dev Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-03-03 21:12 ` Bjorn Helgaas
2017-03-03 21:12 ` Bjorn Helgaas
2017-03-03 21:12 ` Bjorn Helgaas
2017-02-27 19:54 ` [RFC PATCH 20/30] iommu/arm-smmu-v3: Enable PCI PASID in masters Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-05-31 14:10 ` [RFC,20/30] " Sinan Kaya
2017-05-31 14:10 ` Sinan Kaya
2017-05-31 14:10 ` Sinan Kaya
2017-06-01 12:30 ` Jean-Philippe Brucker
2017-06-01 12:30 ` Jean-Philippe Brucker
2017-06-01 12:30 ` Jean-Philippe Brucker
2017-06-01 12:30 ` David Woodhouse
2017-06-01 12:30 ` David Woodhouse
2017-06-01 12:30 ` David Woodhouse
2017-06-23 14:39 ` Sinan Kaya
2017-06-23 14:39 ` Sinan Kaya
2017-06-23 14:39 ` Sinan Kaya
2017-06-23 15:15 ` Jean-Philippe Brucker
2017-06-23 15:15 ` Jean-Philippe Brucker
2017-06-23 15:15 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 21/30] iommu/arm-smmu-v3: Handle device faults from PRI Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
[not found] ` <8520D5D51A55D047800579B0941471982640F43C@XAP-PVEXMBX02.xlnx.xilinx.com>
2017-03-25 5:16 ` valmiki
2017-03-25 5:16 ` valmiki
2017-03-25 5:16 ` valmiki
2017-03-27 11:05 ` Jean-Philippe Brucker
2017-03-27 11:05 ` Jean-Philippe Brucker
2017-03-27 11:05 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 22/30] iommu: Bind/unbind tasks to/from devices Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-03-02 7:29 ` Tian, Kevin
2017-03-02 7:29 ` Tian, Kevin
2017-03-02 7:29 ` Tian, Kevin
2017-03-03 9:40 ` David Woodhouse
2017-03-03 9:40 ` David Woodhouse
2017-03-03 17:05 ` Raj, Ashok
2017-03-03 17:05 ` Raj, Ashok
2017-03-03 17:05 ` Raj, Ashok
2017-03-03 18:39 ` Jean-Philippe Brucker
2017-03-03 18:39 ` Jean-Philippe Brucker
2017-03-03 18:39 ` Jean-Philippe Brucker
2017-03-22 15:36 ` Joerg Roedel
2017-03-22 15:36 ` Joerg Roedel
2017-03-22 15:36 ` Joerg Roedel
2017-03-22 18:30 ` Jean-Philippe Brucker
2017-03-22 18:30 ` Jean-Philippe Brucker
2017-03-22 18:30 ` Jean-Philippe Brucker
2017-03-22 15:38 ` Joerg Roedel
2017-03-22 15:38 ` Joerg Roedel
2017-03-22 15:38 ` Joerg Roedel
2017-02-27 19:54 ` [RFC PATCH 23/30] iommu/arm-smmu-v3: Bind/unbind device and task Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-03-22 15:44 ` Joerg Roedel
2017-03-22 15:44 ` Joerg Roedel
2017-03-22 15:44 ` Joerg Roedel
2017-03-22 18:31 ` Jean-Philippe Brucker
2017-03-22 18:31 ` Jean-Philippe Brucker
2017-03-22 18:31 ` Jean-Philippe Brucker
2017-03-22 22:53 ` Joerg Roedel
2017-03-22 22:53 ` Joerg Roedel
2017-03-22 22:53 ` Joerg Roedel
2017-03-23 13:37 ` Jean-Philippe Brucker
2017-03-23 13:37 ` Jean-Philippe Brucker
2017-03-23 13:37 ` Jean-Philippe Brucker
2017-03-23 14:30 ` Joerg Roedel
2017-03-23 14:30 ` Joerg Roedel
2017-03-23 14:30 ` Joerg Roedel
2017-03-23 15:52 ` Jean-Philippe Brucker
2017-03-23 15:52 ` Jean-Philippe Brucker
2017-03-23 15:52 ` Jean-Philippe Brucker
2017-03-23 16:52 ` Joerg Roedel
2017-03-23 16:52 ` Joerg Roedel
2017-03-23 16:52 ` Joerg Roedel
2017-03-23 17:03 ` Jean-Philippe Brucker
2017-03-23 17:03 ` Jean-Philippe Brucker
2017-03-23 17:03 ` Jean-Philippe Brucker
2017-03-24 11:00 ` Joerg Roedel
2017-03-24 11:00 ` Joerg Roedel
2017-03-24 11:00 ` Joerg Roedel
2017-03-24 19:08 ` Jean-Philippe Brucker [this message]
2017-03-24 19:08 ` Jean-Philippe Brucker
2017-03-24 19:08 ` Jean-Philippe Brucker
2017-03-27 15:33 ` Joerg Roedel
2017-03-27 15:33 ` Joerg Roedel
2017-03-27 15:33 ` Joerg Roedel
2017-02-27 19:54 ` [RFC PATCH 25/30] iommu/arm-smmu-v3: Safe invalidation and recycling of PASIDs Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 26/30] iommu/arm-smmu-v3: Fix PRI queue overflow acknowledgement Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 27/30] iommu/arm-smmu-v3: Handle PRI queue overflow Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 28/30] iommu/arm-smmu-v3: Add support for Hardware Translation Table Update at stage 1 Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` [RFC PATCH 29/30] vfio: Add support for Shared Virtual Memory Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-28 3:54 ` Alex Williamson
2017-02-28 3:54 ` Alex Williamson
2017-02-28 3:54 ` Alex Williamson
2017-02-28 15:17 ` Jean-Philippe Brucker
2017-02-28 15:17 ` Jean-Philippe Brucker
2017-02-28 15:17 ` Jean-Philippe Brucker
2017-03-21 7:04 ` Liu, Yi L
2017-03-21 7:04 ` Liu, Yi L
2017-03-21 7:04 ` Liu, Yi L
2017-03-21 19:37 ` Jean-Philippe Brucker
2017-03-21 19:37 ` Jean-Philippe Brucker
2017-03-21 19:37 ` Jean-Philippe Brucker
2017-03-21 20:56 ` jacob pan
2017-03-21 20:56 ` jacob pan
2017-03-21 20:56 ` jacob pan
2017-03-21 20:56 ` jacob pan
2017-03-23 8:39 ` Liu, Yi L
2017-03-23 8:39 ` Liu, Yi L
2017-03-23 8:39 ` Liu, Yi L
2017-03-23 8:39 ` Liu, Yi L
2017-03-23 13:38 ` Jean-Philippe Brucker
2017-03-23 13:38 ` Jean-Philippe Brucker
2017-03-23 13:38 ` Jean-Philippe Brucker
2017-03-23 13:38 ` Jean-Philippe Brucker
2017-03-24 7:46 ` Liu, Yi L
2017-03-24 7:46 ` Liu, Yi L
2017-03-24 7:46 ` Liu, Yi L
2017-03-24 7:46 ` Liu, Yi L
2017-03-27 10:13 ` Jean-Philippe Brucker
2017-03-27 10:13 ` Jean-Philippe Brucker
2017-03-27 10:13 ` Jean-Philippe Brucker
2017-03-29 6:17 ` Liu, Yi L
2017-03-29 6:17 ` Liu, Yi L
2017-03-29 6:17 ` Liu, Yi L
2017-04-26 6:53 ` Tomasz Nowicki
2017-04-26 6:53 ` Tomasz Nowicki
2017-04-26 6:53 ` Tomasz Nowicki
2017-04-26 10:08 ` Jean-Philippe Brucker
2017-04-26 10:08 ` Jean-Philippe Brucker
2017-04-26 10:08 ` Jean-Philippe Brucker
2017-04-26 11:01 ` Tomasz Nowicki
2017-04-26 11:01 ` Tomasz Nowicki
2017-04-26 11:01 ` Tomasz Nowicki
2017-02-27 19:54 ` [RFC PATCH 30/30] vfio: Allow to bind foreign task Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-27 19:54 ` Jean-Philippe Brucker
2017-02-28 3:54 ` Alex Williamson
2017-02-28 3:54 ` Alex Williamson
2017-02-28 3:54 ` Alex Williamson
2017-02-28 6:43 ` Tian, Kevin
2017-02-28 6:43 ` Tian, Kevin
2017-02-28 6:43 ` Tian, Kevin
2017-02-28 15:22 ` Jean-Philippe Brucker
2017-02-28 15:22 ` Jean-Philippe Brucker
2017-02-28 15:22 ` Jean-Philippe Brucker
2017-03-01 8:02 ` Tian, Kevin
2017-03-01 8:02 ` Tian, Kevin
2017-03-01 8:02 ` Tian, Kevin
2017-03-02 10:50 ` Jean-Philippe Brucker
2017-03-02 10:50 ` Jean-Philippe Brucker
2017-03-02 10:50 ` Jean-Philippe Brucker
2017-04-26 7:25 ` Tomasz Nowicki
2017-04-26 7:25 ` Tomasz Nowicki
2017-04-26 7:25 ` Tomasz Nowicki
2017-04-26 10:08 ` Jean-Philippe Brucker
2017-04-26 10:08 ` Jean-Philippe Brucker
2017-04-26 10:08 ` Jean-Philippe Brucker
2017-03-06 8:20 ` [RFC PATCH 00/30] Add PCIe SVM support to ARM SMMUv3 Liu, Yi L
2017-03-06 8:20 ` Liu, Yi L
2017-03-06 8:20 ` Liu, Yi L
2017-03-06 11:14 ` Jean-Philippe Brucker
2017-03-06 11:14 ` Jean-Philippe Brucker
2017-03-06 11:14 ` Jean-Philippe Brucker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7386120a-2848-059f-4de0-7888a2698923@arm.com \
--to=jean-philippe.brucker@arm.com \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=dwmw2@infradead.org \
--cc=harba@qti.qualcomm.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=nwatters@qti.qualcomm.com \
--cc=okaya@qti.qualcomm.com \
--cc=robin.murphy@arm.com \
--cc=shankerd@qti.qualcomm.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.