On 8/2/2017 12:10 AM, Jean-Philippe Brucker wrote:
On 01/08/17 18:38, valmiki wrote:
[...]
So i digged through your patches and i understood that using BIND ioctls
satge-1 translations are setup in SMMU for an application.
If we use VFIO_IOMMU_MAP/UNMAP_DMA ioctls they are setting up stage-2
tra
The following is roughly the content of topology.tex and MSI.tex
---
\section{Implementation notes}\label{sec:viommu}
\subsection{Virtual system topology}\label{sec:viommu / Virtual topology}
\subsubsection{Example virtual topology}\label{sec:viommu / Virtual topology /
Example}
\begin{figure}
The following is roughly the content of device-operations.tex
---
\section{IOMMU device}\label{sec:Device Types / IOMMU Device}
The virtio-iommu device manages Direct Memory Access (DMA) from one or
more endpoints. It may act as a proxy for multiple physical IOMMUs
managing devices assigned to th
This is the continuation of my proposal for virtio-iommu, the para-
virtualized IOMMU. Here is a summary of the changes since last time [1]:
* The virtio-iommu document now resembles an actual specification. It is
split into a formal description of the virtio device, and implementation
notes.
On 03/08/17 06:35, Vivek Gautam wrote:
> Hi Robin,
>
>
>
> On 08/02/2017 05:47 PM, Robin Murphy wrote:
>> On 02/08/17 10:53, Vivek Gautam wrote:
>>> We don't want to touch the TLB when smmu is suspended.
>>> Defer it until resume.
>>>
>>> Signed-off-by: Vivek Gautam
>>> ---
>>>
>>> Hi all,
>>>
On 01/08/17 11:49, Shameer Kolothum wrote:
> On some platforms ITS address regions have to be excluded from normal
> IOVA allocation in that they are detected and decoded in a HW specific
> way by system components and so they cannot be considered normal IOVA
> address space.
>
> Add an helper fun
Sudeep reports that the logic got slightly broken when a PCI iommu-map
entry targets an IOMMU marked as disabled in DT, since of_pci_map_rid()
succeeds in following a phandle, and of_iommu_xlate() doesn't return an
error value, but we miss checking whether ops was actually non-NULL.
Whilst this cou
On 04/08/17 12:16, Robin Murphy wrote:
> Sudeep reports that the logic is slightly broken when a PCI iommu-map
> entry targets an IOMMU marked as disabled in DT, since of_pci_map_rid()
> succeeds in following a phandle, and of_iommu_xlate() doesn't return an
> error value, but we miss checking whet
On 08/04/2017 12:06 PM, Joerg Roedel wrote:
On Fri, Aug 04, 2017 at 09:32:24AM +0800, honghui.zh...@mediatek.com wrote:
Honghui Zhang (4):
memory: mtk-smi: Use of_device_get_match_data helper
memory: mtk-smi: add larbid handle routine
dt-bindings: mediatek: add descriptions for larbid
On Fri, Aug 04, 2017 at 09:13:20PM +0800, Baoquan He wrote:
> On 08/04/17 at 02:30pm, Joerg Roedel wrote:
> > On Tue, Aug 01, 2017 at 07:37:28PM +0800, Baoquan He wrote:
> > > @@ -2466,11 +2472,21 @@ static struct protection_domain
> > > *get_domain(struct device *dev)
> > > return ERR_P
On 08/04/17 at 02:30pm, Joerg Roedel wrote:
> On Tue, Aug 01, 2017 at 07:37:28PM +0800, Baoquan He wrote:
> > @@ -2466,11 +2472,21 @@ static struct protection_domain *get_domain(struct
> > device *dev)
> > return ERR_PTR(-EINVAL);
> >
> > domain = get_dev_data(dev)->domain;
> > -
On 08/04/17 at 02:21pm, Joerg Roedel wrote:
> On Tue, Aug 01, 2017 at 07:37:22PM +0800, Baoquan He wrote:
> > static void init_device_table_dma(void)
> > {
> > @@ -2137,9 +2140,49 @@ static void early_enable_iommu(struct amd_iommu
> > *iommu)
> > static void early_enable_iommus(void)
> > {
> >
On 08/04/17 at 02:25pm, Joerg Roedel wrote:
> On Tue, Aug 01, 2017 at 07:37:26PM +0800, Baoquan He wrote:
> > AMD pointed out it's unsafe to update the device-table while iommu
> > is enabled. It turns out that device-table pointer update is split
> > up into two 32bit writes in the IOMMU hardware.
On 08/04/17 at 02:51pm, Joerg Roedel wrote:
> On Fri, Aug 04, 2017 at 08:30:39PM +0800, Baoquan He wrote:
> > Sorry, I don't get 'this one' meaning, are you suggesting the copy for
> > loop should be take out of the iommu for loop?
> >
> > About the temporary copy of the old device-table, you can
On 04/08/17 12:16, Robin Murphy wrote:
> Sudeep reports that the logic is slightly broken when a PCI iommu-map
> entry targets an IOMMU marked as disabled in DT, since of_pci_map_rid()
> succeeds in following a phandle, and of_iommu_xlate() doesn't return an
> error value, but we miss checking wh
On Fri, Aug 04, 2017 at 08:30:39PM +0800, Baoquan He wrote:
> Sorry, I don't get 'this one' meaning, are you suggesting the copy for
> loop should be take out of the iommu for loop?
>
> About the temporary copy of the old device-table, you can see in patch
> 7/13, if irq sanity check failed, it r
On 08/04/17 at 02:09pm, Joerg Roedel wrote:
>
> On Tue, Aug 01, 2017 at 07:37:21PM +0800, Baoquan He wrote:
> > + for_each_iommu(iommu) {
..
> > + if (copied)
> > + continue;
> > +
> > + old_devtb_phys = entry & PAGE_MASK;
> > + old_d
On Tue, Aug 01, 2017 at 07:37:27PM +0800, Baoquan He wrote:
> @@ -908,6 +911,14 @@ static int copy_device_table(void)
> old_dev_tbl_cpy[devid].data[1]
> = old_devtb[devid].data[1];
> __set_bit(dom_id,
On Tue, Aug 01, 2017 at 07:37:28PM +0800, Baoquan He wrote:
> @@ -2466,11 +2472,21 @@ static struct protection_domain *get_domain(struct
> device *dev)
> return ERR_PTR(-EINVAL);
>
> domain = get_dev_data(dev)->domain;
> - if (domain == NULL && get_dev_data(dev)->defer_at
On Tue, Aug 01, 2017 at 07:37:26PM +0800, Baoquan He wrote:
> AMD pointed out it's unsafe to update the device-table while iommu
> is enabled. It turns out that device-table pointer update is split
> up into two 32bit writes in the IOMMU hardware. So updating it while
> the IOMMU is enabled could h
On Tue, Aug 01, 2017 at 07:37:22PM +0800, Baoquan He wrote:
> static void init_device_table_dma(void)
> {
> @@ -2137,9 +2140,49 @@ static void early_enable_iommu(struct amd_iommu *iommu)
> static void early_enable_iommus(void)
> {
> struct amd_iommu *iommu;
> + bool is_pre_disabled =
Hi Joerg,
Thanks for your reviewing!
On 08/04/17 at 02:09pm, Joerg Roedel wrote:
> Hi Baoquan,
>
> On Tue, Aug 01, 2017 at 07:37:21PM +0800, Baoquan He wrote:
> > + for_each_iommu(iommu) {
> > + /* All IOMMUs should use the same device table with the same
> > size */
> > +
Hi Baoquan,
On Tue, Aug 01, 2017 at 07:37:21PM +0800, Baoquan He wrote:
> + for_each_iommu(iommu) {
> + /* All IOMMUs should use the same device table with the same
> size */
> + lo = readl(iommu->mmio_base + MMIO_DEV_TABLE_OFFSET);
> + hi = readl(iommu->mm
Sudeep reports that the logic is slightly broken when a PCI iommu-map
entry targets an IOMMU marked as disabled in DT, since of_pci_map_rid()
succeeds in following a phandle, and of_iommu_xlate() doesn't return an
error value, but we miss checking whether ops was actually non-NULL.
Whilst this coul
On Fri, Aug 04, 2017 at 12:28:33PM +0200, Marek Szyprowski wrote:
> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for
> platform/amba/pci bus devices") postponed the moment of attaching IOMMU
> controller to its device, so there is no need to register IOMMU controllers
> ver
Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for
platform/amba/pci bus devices") postponed the moment of attaching IOMMU
controller to its device, so there is no need to register IOMMU controllers
very early, before all other devices in the system. This change gives us an
o
On Fri, Aug 04, 2017 at 09:32:24AM +0800, honghui.zh...@mediatek.com wrote:
> Honghui Zhang (4):
> memory: mtk-smi: Use of_device_get_match_data helper
> memory: mtk-smi: add larbid handle routine
> dt-bindings: mediatek: add descriptions for larbid
> arm: dts: mediatek: add larbid property
On Fri, Jul 28, 2017 at 03:49:12PM -0500, Josue Albarran wrote:
> Fernando Guzman Lugo (1):
> iommu/omap: Fix disabling of MMU upon a fault
>
> Josue Albarran (1):
> iommu/omap: Use DMA-API for performing cache flushes
>
> drivers/iommu/omap-iommu.c | 125
> +
On Fri, Jul 28, 2017 at 03:19:19PM +0200, Arnd Bergmann wrote:
> Since we print the correct warning, an allmodconfig build is no longer
> clean but always prints it, which defeats compile-testing:
>
> drivers/iommu/exynos-iommu.c:58:2: error: #warning "revisit driver if we can
> enable big-endian
On Wed, Aug 02, 2017 at 10:02:50AM +0800, Honghui Zhang wrote:
> On Wed, 2017-07-26 at 20:37 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang
> >
> > Replace custom code with generic helper to retrieve driver data.
>
> Hi, Joerg, would you please take this one, because my last
>
On Tue, Aug 01, 2017 at 04:42:50PM -0600, Alex Williamson wrote:
> Generally that's fine, your post will get delayed until Joerg or I
> approve it, but it should get there eventually. Probably just a
> mis-click caused you to end up on the wrong list. I still don't see
> you on the subscriber lis
Hi Kevin,
On 04/08/17 02:49, Tian, Kevin wrote:
>> From: Jean-Philippe Brucker
>> Sent: Tuesday, August 1, 2017 4:26 PM
>>
>> It depends what type you use when registering the IOMMU with
>> VFIO_SET_IOMMU:
>>
>> * If the type is VFIO_TYPE1v2_IOMMU, then
>> VFIO_IOMMU_MAP/UNMAP_DMA
>> affects the
Hi Linus,
The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:
Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v4.13-rc3
for you to fetch changes up to
33 matches
Mail list logo