RE: [RFC] virtio-iommu version 0.4

[Bharat Bhushan]

Hi Eric,

> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: Tuesday, September 12, 2017 10:43 PM
> To: Jean-Philippe Brucker ;
> iommu@lists.linux-foundation.org; k...@vger.kernel.org;
> virtualizat...@lists.linux-foundation.org; virtio-...@lists.oasis-open.org
> Cc: will.dea...@arm.com; robin.mur...@arm.com;
> lorenzo.pieral...@arm.com; m...@redhat.com; jasow...@redhat.com;
> marc.zyng...@arm.com; eric.auger@gmail.com; Bharat Bhushan
> ; pet...@redhat.com; kevin.t...@intel.com
> Subject: Re: [RFC] virtio-iommu version 0.4
> 
> Hi jean,
> 
> On 04/08/2017 20:19, Jean-Philippe Brucker wrote:
> > 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. Please find sources and binaries at [2].
> >
> > * Added a probe request to describe to the guest different properties that
> >   do not fit in firmware or in the virtio config space. This is a
> >   necessary stepping stone for extending the virtio-iommu.
> >
> > * There is a working Qemu prototype [3], thanks to Eric Auger and Bharat
> >   Bhushan.
> >
> > You can find the Linux driver and kvmtool device at [4] and [5]. I
> > plan to rework driver and kvmtool device slightly before sending the
> > patches.
> >
> > To understand the virtio-iommu, I advise to first read introduction
> > and motivation, then skim through implementation notes and finally
> > look at the device specification.
> >
> > I wasn't sure how to organize the review. For those who prefer to
> > comment inline, I attached v0.4 of device-operations.tex and
> > topology.tex+MSI.tex to this thread. They are the biggest chunks of
> > the document. But LaTeX isn't very pleasant to read, so you can simply
> > send a list of comments in relation to section numbers and a few words of
> context, we'll manage.
> >
> > ---
> > Version numbers 0.1-0.4 are arbitrary. I'm hoping they allow to
> > compare more easily differences since the RFC (see [6]), but haven't
> > been made public so far. This is the first public posting since
> > initial proposal [1], and the following describes all changes.
> >
> > ## v0.1 ##
> >
> > Content is the same as the RFC, but formatted to LaTeX. 'make'
> > generates one PDF and one HTML document.
> >
> > ## v0.2 ##
> >
> > Add introductions, improve topology example and firmware description
> > based on feedback and a number of useful discussions.
> >
> > ## v0.3 ##
> >
> > Add normative sections (MUST, SHOULD, etc). Clarify some things,
> > tighten the device and driver behaviour. Unmap semantics are
> > consolidated; they are now closer to VFIO Type1 v2 semantics.
> >
> > ## v0.4 ##
> >
> > Introduce PROBE requests. They provide per-endpoint information to the
> > driver that couldn't be described otherwise.
> >
> > For the moment, they allow to handle MSIs on x86 virtual platforms
> > (see 3.2). To do that we communicate reserved IOVA regions, that will
> > also be useful for describing regions that cannot be mapped for a
> > given endpoint, for instance addresses that correspond to a PCI bridge
> window.
> >
> > Introducing such a large framework for this tiny feature may seem
> > overkill, but it is needed for future extensions of the virtio-iommu
> > and I believe it really is worth the effort.
> 
> 2.6.7
> - As I am currently integrating v0.4 in QEMU here are some other comments:
> At the moment struct virtio_iommu_req_probe flags is missing in your
> header. As such I understood the ACK protocol was not implemented by the
> driver in your branch.
> - VIRTIO_IOMMU_PROBE_PROPERTY_TYPE_MASK is
> VIRTIO_IOMMU_T_MASK in your header too.
> 2.6.8.2:
> - I am really confused about what the device should report as resv regions
> depending on the PE nature (VFIO or not VFIO)
> 
> In other iommu drivers, the resv regions are populated by the iommu driver
> through its get_resv_regions callback. They are usually composed of an
> iommu specific MSI region (mapped or bypassed) and non IOMMU specific
> (device specific) reserved regions:
> iommu_dma_get_resv_regions(). In the case of virtio-iommu driver, those
> are the guest reserved regions.
> 
> First in the current virtio-iommu driver I don't see the
> iommu_dma_get_resv_regions call. Do you agree that the virtio-iommu
> driver should compute the non IOMMU specific MSI regions. ie. this is not
> the responsability of the virtio-iommu device.
> 
> Then why is it more the job of the device to return the guest iommu specific
> region rather than the driver itself?
> 
> Then I understand this is the responsability of the virtio-iommu device to
> gather information about the host resv regions in case of VFIO EP.
> Typically the host PCIe host bridge windows cannot be used for 

Re: [RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

[Will Deacon]

On Tue, Sep 05, 2017 at 01:54:19PM +0100, Jean-Philippe Brucker wrote:
> On 31/08/17 09:20, Yisheng Xie wrote:
> > It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which
> > means we should not disable stall mode if stall/terminate mode is not
> > configuable.
> > 
> > Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which
> > means if stall mode is force we should always set CD.S.
> > 
> > This patch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use
> > TERMINATE feature checking to ensue above ILLEGAL cases from happening.
> > 
> > Signed-off-by: Yisheng Xie 
> > ---
> >  drivers/iommu/arm-smmu-v3.c | 22 --
> >  1 file changed, 16 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> > index dbda2eb..0745522 100644
> > --- a/drivers/iommu/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm-smmu-v3.c
> > @@ -55,6 +55,7 @@
> >  #define IDR0_STALL_MODEL_SHIFT 24
> >  #define IDR0_STALL_MODEL_MASK  0x3
> >  #define IDR0_STALL_MODEL_STALL (0 << IDR0_STALL_MODEL_SHIFT)
> > +#define IDR0_STALL_MODEL_NS(1 << IDR0_STALL_MODEL_SHIFT)
> >  #define IDR0_STALL_MODEL_FORCE (2 << IDR0_STALL_MODEL_SHIFT)
> >  #define IDR0_TTENDIAN_SHIFT21
> >  #define IDR0_TTENDIAN_MASK 0x3
> > @@ -766,6 +767,7 @@ struct arm_smmu_device {
> >  #define ARM_SMMU_FEAT_SVM  (1 << 15)
> >  #define ARM_SMMU_FEAT_HA   (1 << 16)
> >  #define ARM_SMMU_FEAT_HD   (1 << 17)
> > +#define ARM_SMMU_FEAT_TERMINATE(1 << 18)
> 
> I'd rather introduce something like "ARM_SMMU_FEAT_STALL_FORCE" instead.
> Terminate model has another meaning, and is defined by a different bit in
> IDR0.

Yes. What we need to do is:

- If STALL_MODEL is 0b00, then set S1STALLD
- If STALL_MODEL is 0b01, then we're ok (in future, avoiding trying to use
  stalls, even for masters that claim to support it)
- If STALL_MODEL is 0b10, then force all PCI devices and any platform
  devices that don't claim to support stalls into bypass (depending on
  disable_bypass).

Reasonable? We could actually knock up a fix for mainline to do most of
this already.

Will
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: VFIO on ARM64

[Jean-Philippe Brucker]

Hi Valmiki,

On 12/09/17 19:01, valmiki wrote:
> Hi, as per VFIO documentation i see that we need to see
> "/sys/bus/pci/devices/:06:0d.0/iommu_group" in order to find group
> in which PCI bus is attached.
> But as per drivers/pci/pci-sysfs.c in static struct attribute
> *pci_dev_attrs[], i don't see any such attribute.

This iommu_group attribute is created by
drivers/iommu/iommu.c:iommu_group_add_device. It is a symbolic link to
/sys/kernel/iommu_groups/.

> I tried enabling SMMUv2 driver and SMMU for PCIe node on our SOC, but
> this file doesn't show up and also in /sys/kernel/iommu_group i do not
> see "/sys/kernel/iommu_groups/17/devices/:00:1f.00" file, i see only
> PCIe root port device tree node in that group and not individual buses.
> So on ARM64 for showing these paths i.e show specific to each bus, does
> SMMU need any particular confguration (we have SMMUv2) > Do we need any 
> specific kernel configuration ?

I don't think so. If you're able to see the root complex in an IOMMU
group, then the configuration is probably fine. Could you provide a little
more information about your system, for example lspci along with "find
/sys/kernel/iommu_groups/*/devices/*"?

Ideally, each PCIe device will be in its own IOMMU group. So you shouldn't
have each bus in a group, but rather one device per group. Linux puts
multiple devices in a group if the IOMMU cannot properly isolate them. In
general it's not something you want in your system, because all devices in
a group will have the same address space and cannot be passed to a guest
separately.

Thanks,
Jean
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

[Bob Liu]

On 2017/9/6 17:57, Jean-Philippe Brucker wrote:
> On 06/09/17 02:02, Bob Liu wrote:
>> On 2017/9/5 20:56, Jean-Philippe Brucker wrote:
>>> On 31/08/17 09:20, Yisheng Xie wrote:
 Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM 
 SMMUv3:
 https://www.spinics.net/lists/arm-kernel/msg565155.html

 But for some platform devices(aka on-chip integrated devices), there is 
 also
 SVM requirement, which works based on the SMMU stall mode.
 Jean-Philippe has prepared a prototype patchset to support it:
 git://linux-arm.org/linux-jpb.git svm/stall
>>>
>>> Only meant for testing at that point, and unfit even for an RFC.
>>>
>>
>> Sorry for the misunderstanding.
>> The PRI mode patches is in RFC even no hardware for testing, so I thought 
>> it's fine for "Stall mode" patches sent as RFC.
>> We have tested the Stall mode on our platform.
>> Anyway, I should confirm with you in advance.
>>
>> Btw, Would you consider the "stall mode" upstream at first? Since there is 
>> no hardware for testing the PRI mode.
>> (We can provide you the hardware which support SMMU stall mode if necessary.)
> 
> Yes. What's blocking the ATS, PRI and PASID patches at the moment is the
> lack of endpoints for testing. There has been lots of discussion on the
> API side since my first RFC and I'd like to resubmit the API changes soon.
> It is the same API for ATS+PRI+PASID and SSID+Stall, so the backend
> doesn't matter.
> 
> I'm considering upstreaming SSID+Stall first if it can be tested on
> hardware (having direct access to it would certainly speed things up).
> This would require some work in moving the PCI bits at the end of the
> series. I can reserve some time in the coming months to do it, but I need
> to know what to focus on. Are you able to test SSID as well?
> 

Update:
Our current platform device has only one SSID register, so that have to do 
manually 
switch(write different ssid to that register) if want to use by different 
processes.

But we're going to have an new platform who's platform device can support multi 
ssid.

Regards,
Bob

 We tested this patchset with some fixes on a on-chip integrated device. The
 basic function is ok, so I just send them out for review, although this
 patchset heavily depends on the former patchset (PCIe SVM support for ARM
 SMMUv3), which is still under discussion.

 Patch Overview:
 *1 to 3 prepare for device tree or acpi get the device stall ability and 
 pasid bits
 *4 is to realise the SVM function for platform device
 *5 is fix a bug when test SVM function while SMMU donnot support this 
 feature
 *6 avoid ILLEGAL setting of STE and CD entry about stall

 Acctually here, I also have a question about SVM on SMMUv3:

 1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task 
 to device,
it will register a mmu_notify. Therefore, when a page range is invalid, 
 we can
send TLBI or ATC invalid without BTM?
>>>
>>> We could, but the end goal for SVM is to perfectly mirror the CPU page
>>> tables. So for platform SVM we would like to get rid of MMU notifiers
>>> entirely.
>>>
 2. According to ACPI IORT spec, named component specific data has a node 
 flags field
whoes bit0 is for Stall support. However, it do not have any field for 
 pasid bit.
Can we use other 5 bits[5:1] for pasid bit numbers, so we can have 32 
 pasid bit for
a single platform device which should be enough, because SMMU only 
 support 20 bit pasid

>>
>> Any comment on this?
>> The ACPI IORT spec may need be updated?
> 
> I suppose that the Named Component Node could be used for SSID and stall
> capability bits. Can't the ACPI namespace entries be extended to host
> these capabilities in a more generic way? Platforms with different IOMMUs
> might also need this information some day.
> 


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] iommu: dmar: fix harmless section mismatch warning

[Arnd Bergmann]

Building with gcc-4.6 results in this warning due to
dmar_table_print_dmar_entry being inlined as in newer compiler versions:

WARNING: vmlinux.o(.text+0x5c8bee): Section mismatch in reference from the 
function dmar_walk_remapping_entries() to the function 
.init.text:dmar_table_print_dmar_entry()
The function dmar_walk_remapping_entries() references
the function __init dmar_table_print_dmar_entry().
This is often because dmar_walk_remapping_entries lacks a __init
annotation or the annotation of dmar_table_print_dmar_entry is wrong.

This removes the __init annotation to avoid the warning. On compilers
that don't show the warning today, this should have no impact since the
function gets inlined anyway.

Signed-off-by: Arnd Bergmann 
---
 drivers/iommu/dmar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index ca5ebaeafd6a..57c920c1372d 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -497,7 +497,7 @@ static int dmar_parse_one_rhsa(struct acpi_dmar_header 
*header, void *arg)
 #definedmar_parse_one_rhsa dmar_res_noop
 #endif
 
-static void __init
+static void
 dmar_table_print_dmar_entry(struct acpi_dmar_header *header)
 {
struct acpi_dmar_hardware_unit *drhd;
-- 
2.9.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: VFIO on ARM64

[Alex Williamson]

[Cc +Eric Auger]

On Tue, 12 Sep 2017 23:31:00 +0530
valmiki  wrote:

> Hi, as per VFIO documentation i see that we need to see 
> "/sys/bus/pci/devices/:06:0d.0/iommu_group" in order to find group 
> in which PCI bus is attached.
> But as per drivers/pci/pci-sysfs.c in static struct attribute 
> *pci_dev_attrs[], i don't see any such attribute.
> I tried enabling SMMUv2 driver and SMMU for PCIe node on our SOC, but 
> this file doesn't show up and also in /sys/kernel/iommu_group i do not 
> see "/sys/kernel/iommu_groups/17/devices/:00:1f.00" file, i see only 
> PCIe root port device tree node in that group and not individual buses.
> So on ARM64 for showing these paths i.e show specific to each bus, does 
> SMMU need any particular confguration (we have SMMUv2) ?
> Do we need any specific kernel configuration ?
> 
> 
> Regards,
> Valmiki
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

VFIO on ARM64

[valmiki]

Hi, as per VFIO documentation i see that we need to see 
"/sys/bus/pci/devices/:06:0d.0/iommu_group" in order to find group 
in which PCI bus is attached.
But as per drivers/pci/pci-sysfs.c in static struct attribute 
*pci_dev_attrs[], i don't see any such attribute.
I tried enabling SMMUv2 driver and SMMU for PCIe node on our SOC, but 
this file doesn't show up and also in /sys/kernel/iommu_group i do not 
see "/sys/kernel/iommu_groups/17/devices/:00:1f.00" file, i see only 
PCIe root port device tree node in that group and not individual buses.
So on ARM64 for showing these paths i.e show specific to each bus, does 
SMMU need any particular confguration (we have SMMUv2) ?

Do we need any specific kernel configuration ?


Regards,
Valmiki

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC] virtio-iommu version 0.4

[Auger Eric]

Hi jean,

On 04/08/2017 20:19, Jean-Philippe Brucker wrote:
> 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. Please find sources and binaries at [2].
> 
> * Added a probe request to describe to the guest different properties that
>   do not fit in firmware or in the virtio config space. This is a
>   necessary stepping stone for extending the virtio-iommu.
> 
> * There is a working Qemu prototype [3], thanks to Eric Auger and Bharat
>   Bhushan.
> 
> You can find the Linux driver and kvmtool device at [4] and [5]. I
> plan to rework driver and kvmtool device slightly before sending the
> patches.
> 
> To understand the virtio-iommu, I advise to first read introduction and
> motivation, then skim through implementation notes and finally look at the
> device specification.
> 
> I wasn't sure how to organize the review. For those who prefer to comment
> inline, I attached v0.4 of device-operations.tex and topology.tex+MSI.tex
> to this thread. They are the biggest chunks of the document. But LaTeX
> isn't very pleasant to read, so you can simply send a list of comments in
> relation to section numbers and a few words of context, we'll manage.
> 
> ---
> Version numbers 0.1-0.4 are arbitrary. I'm hoping they allow to compare
> more easily differences since the RFC (see [6]), but haven't been made
> public so far. This is the first public posting since initial proposal
> [1], and the following describes all changes.
> 
> ## v0.1 ##
> 
> Content is the same as the RFC, but formatted to LaTeX. 'make' generates
> one PDF and one HTML document.
> 
> ## v0.2 ##
> 
> Add introductions, improve topology example and firmware description based
> on feedback and a number of useful discussions.
> 
> ## v0.3 ##
> 
> Add normative sections (MUST, SHOULD, etc). Clarify some things, tighten
> the device and driver behaviour. Unmap semantics are consolidated; they
> are now closer to VFIO Type1 v2 semantics.
> 
> ## v0.4 ##
> 
> Introduce PROBE requests. They provide per-endpoint information to the
> driver that couldn't be described otherwise.
> 
> For the moment, they allow to handle MSIs on x86 virtual platforms (see
> 3.2). To do that we communicate reserved IOVA regions, that will also be
> useful for describing regions that cannot be mapped for a given endpoint,
> for instance addresses that correspond to a PCI bridge window.
> 
> Introducing such a large framework for this tiny feature may seem
> overkill, but it is needed for future extensions of the virtio-iommu and I
> believe it really is worth the effort.

2.6.7
- As I am currently integrating v0.4 in QEMU here are some other comments:
At the moment struct virtio_iommu_req_probe flags is missing in your
header. As such I understood the ACK protocol was not implemented by the
driver in your branch.
- VIRTIO_IOMMU_PROBE_PROPERTY_TYPE_MASK is VIRTIO_IOMMU_T_MASK in your
header too.
2.6.8.2:
- I am really confused about what the device should report as resv
regions depending on the PE nature (VFIO or not VFIO)

In other iommu drivers, the resv regions are populated by the iommu
driver through its get_resv_regions callback. They are usually composed
of an iommu specific MSI region (mapped or bypassed) and non IOMMU
specific (device specific) reserved regions:
iommu_dma_get_resv_regions(). In the case of virtio-iommu driver, those
are the guest reserved regions.

First in the current virtio-iommu driver I don't see the
iommu_dma_get_resv_regions call. Do you agree that the virtio-iommu
driver should compute the non IOMMU specific MSI regions. ie. this is
not the responsability of the virtio-iommu device.

Then why is it more the job of the device to return the guest iommu
specific region rather than the driver itself?

Then I understand this is the responsability of the virtio-iommu device
to gather information about the host resv regions in case of VFIO EP.
Typically the host PCIe host bridge windows cannot be used for IOVA.
Also the host MSI reserved IOVA window cannot be used. Do you agree.

I really think the spec should clarify what exact resv regions the
device should return in case of VFIO device and non VFIO device.

Thanks

Eric

> 
> ## Future ##
> 
> Other extensions are in preparation. I won't detail them here because v0.4
> already is a lot to digest, but in short, building on top of PROBE:
> 
> * First, since the IOMMU is paravirtualized, the device can expose some
>   properties of the physical topology to the guest, and let it allocate
>   resources more efficiently. For example, when the virtio-iommu manages
>   both physical and emulated endpoints, with different underlying IOMMUs,
>   we now have a way to describe multiple page and block granularities,
>   instead of forcing the guest to use 

[PATCH v2 1/3] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

[Zhen Lei]

Because all TLBI commands should be followed by a SYNC command, to make
sure that it has been completely finished. So we can just add the TLBI
commands into the queue, and put off the execution until meet SYNC or
other commands. To prevent the followed SYNC command waiting for a long
time because of too many commands have been delayed, restrict the max
delayed number.

According to my test, I got the same performance data as I replaced writel
with writel_relaxed in queue_inc_prod.

Signed-off-by: Zhen Lei 
---
 drivers/iommu/arm-smmu-v3.c | 42 +-
 1 file changed, 37 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index e67ba6c..ef42c4b 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -337,6 +337,7 @@
 /* Command queue */
 #define CMDQ_ENT_DWORDS2
 #define CMDQ_MAX_SZ_SHIFT  8
+#define CMDQ_MAX_DELAYED   32
 
 #define CMDQ_ERR_SHIFT 24
 #define CMDQ_ERR_MASK  0x7f
@@ -482,6 +483,7 @@ struct arm_smmu_cmdq_ent {
};
} cfgi;
 
+   #define CMDQ_OP_TLBI_NH_ALL 0x10
#define CMDQ_OP_TLBI_NH_ASID0x11
#define CMDQ_OP_TLBI_NH_VA  0x12
#define CMDQ_OP_TLBI_EL2_ALL0x20
@@ -509,6 +511,7 @@ struct arm_smmu_cmdq_ent {
 
 struct arm_smmu_queue {
int irq; /* Wired interrupt */
+   u32 nr_delay;
 
__le64  *base;
dma_addr_t  base_dma;
@@ -745,11 +748,16 @@ static int queue_sync_prod(struct arm_smmu_queue *q)
return ret;
 }
 
-static void queue_inc_prod(struct arm_smmu_queue *q)
+static void queue_inc_swprod(struct arm_smmu_queue *q)
 {
-   u32 prod = (Q_WRP(q, q->prod) | Q_IDX(q, q->prod)) + 1;
+   u32 prod = q->prod + 1;
 
q->prod = Q_OVF(q, q->prod) | Q_WRP(q, prod) | Q_IDX(q, prod);
+}
+
+static void queue_inc_prod(struct arm_smmu_queue *q)
+{
+   queue_inc_swprod(q);
writel(q->prod, q->prod_reg);
 }
 
@@ -791,13 +799,24 @@ static void queue_write(__le64 *dst, u64 *src, size_t 
n_dwords)
*dst++ = cpu_to_le64(*src++);
 }
 
-static int queue_insert_raw(struct arm_smmu_queue *q, u64 *ent)
+static int queue_insert_raw(struct arm_smmu_queue *q, u64 *ent, int optimize)
 {
if (queue_full(q))
return -ENOSPC;
 
queue_write(Q_ENT(q, q->prod), ent, q->ent_dwords);
-   queue_inc_prod(q);
+
+   /*
+* We don't want too many commands to be delayed, this may lead the
+* followed sync command to wait for a long time.
+*/
+   if (optimize && (++q->nr_delay < CMDQ_MAX_DELAYED)) {
+   queue_inc_swprod(q);
+   } else {
+   queue_inc_prod(q);
+   q->nr_delay = 0;
+   }
+
return 0;
 }
 
@@ -939,6 +958,7 @@ static void arm_smmu_cmdq_skip_err(struct arm_smmu_device 
*smmu)
 static void arm_smmu_cmdq_issue_cmd(struct arm_smmu_device *smmu,
struct arm_smmu_cmdq_ent *ent)
 {
+   int optimize = 0;
u64 cmd[CMDQ_ENT_DWORDS];
unsigned long flags;
bool wfe = !!(smmu->features & ARM_SMMU_FEAT_SEV);
@@ -950,8 +970,17 @@ static void arm_smmu_cmdq_issue_cmd(struct arm_smmu_device 
*smmu,
return;
}
 
+   /*
+* All TLBI commands should be followed by a sync command later.
+* The CFGI commands is the same, but they are rarely executed.
+* So just optimize TLBI commands now, to reduce the "if" judgement.
+*/
+   if ((ent->opcode >= CMDQ_OP_TLBI_NH_ALL) &&
+   (ent->opcode <= CMDQ_OP_TLBI_NSNH_ALL))
+   optimize = 1;
+
spin_lock_irqsave(>cmdq.lock, flags);
-   while (queue_insert_raw(q, cmd) == -ENOSPC) {
+   while (queue_insert_raw(q, cmd, optimize) == -ENOSPC) {
if (queue_poll_cons(q, false, wfe))
dev_err_ratelimited(smmu->dev, "CMDQ timeout\n");
}
@@ -2001,6 +2030,8 @@ static int arm_smmu_init_one_queue(struct arm_smmu_device 
*smmu,
 << Q_BASE_LOG2SIZE_SHIFT;
 
q->prod = q->cons = 0;
+   q->nr_delay = 0;
+
return 0;
 }
 
@@ -2584,6 +2615,7 @@ static int arm_smmu_device_hw_probe(struct 
arm_smmu_device *smmu)
dev_err(smmu->dev, "unit-length command queue not supported\n");
return -ENXIO;
}
+   BUILD_BUG_ON(CMDQ_MAX_DELAYED >= (1 << CMDQ_MAX_SZ_SHIFT));
 
smmu->evtq.q.max_n_shift = min((u32)EVTQ_MAX_SZ_SHIFT,
   reg >> IDR1_EVTQ_SHIFT & IDR1_EVTQ_MASK);
-- 
2.5.0


___
iommu mailing list
iommu@lists.linux-foundation.org

[PATCH v2 3/3] iommu/arm-smmu: add support for unmap a memory range with only one tlb sync

[Zhen Lei]

This patch is base on: 
(add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing")

Because iotlb_sync is moved out of ".unmap = arm_smmu_unmap", some interval
".unmap" calls should explicitly followed by a iotlb_sync operation.

Signed-off-by: Zhen Lei 
---
 drivers/iommu/arm-smmu.c   | 10 ++
 drivers/iommu/io-pgtable-arm-v7s.c | 32 +---
 2 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 3bdb799..bb57d67 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1259,6 +1259,15 @@ static size_t arm_smmu_unmap(struct iommu_domain 
*domain, unsigned long iova,
return ops->unmap(ops, iova, size);
 }
 
+static void arm_smmu_iotlb_sync(struct iommu_domain *domain)
+{
+   struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+   struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
+
+   if (ops && ops->iotlb_sync)
+   ops->iotlb_sync(ops);
+}
+
 static phys_addr_t arm_smmu_iova_to_phys_hard(struct iommu_domain *domain,
  dma_addr_t iova)
 {
@@ -1561,6 +1570,7 @@ static struct iommu_ops arm_smmu_ops = {
.attach_dev = arm_smmu_attach_dev,
.map= arm_smmu_map,
.unmap  = arm_smmu_unmap,
+   .iotlb_sync = arm_smmu_iotlb_sync,
.map_sg = default_iommu_map_sg,
.iova_to_phys   = arm_smmu_iova_to_phys,
.add_device = arm_smmu_add_device,
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c 
b/drivers/iommu/io-pgtable-arm-v7s.c
index d665d0d..457ad29 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -370,6 +370,8 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
 
for (i = 0; i < num_entries; i++)
if (ARM_V7S_PTE_IS_TABLE(ptep[i], lvl)) {
+   size_t unmapped;
+
/*
 * We need to unmap and free the old table before
 * overwriting it with a block entry.
@@ -378,8 +380,10 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable 
*data,
size_t sz = ARM_V7S_BLOCK_SIZE(lvl);
 
tblp = ptep - ARM_V7S_LVL_IDX(iova, lvl);
-   if (WARN_ON(__arm_v7s_unmap(data, iova + i * sz,
-   sz, lvl, tblp) != sz))
+   unmapped = __arm_v7s_unmap(data, iova + i * sz,
+   sz, lvl, tblp);
+   io_pgtable_tlb_sync(>iop);
+   if (WARN_ON(unmapped != sz))
return -EINVAL;
} else if (ptep[i]) {
/* We require an unmap first */
@@ -633,7 +637,6 @@ static int __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
/* Also flush any partial walks */
io_pgtable_tlb_add_flush(iop, iova, blk_size,
ARM_V7S_BLOCK_SIZE(lvl + 1), false);
-   io_pgtable_tlb_sync(iop);
ptep = iopte_deref(pte[i], lvl);
__arm_v7s_free_table(ptep, lvl + 1, data);
} else {
@@ -660,16 +663,18 @@ static int arm_v7s_unmap(struct io_pgtable_ops *ops, 
unsigned long iova,
 size_t size)
 {
struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
-   size_t unmapped;
 
if (WARN_ON(upper_32_bits(iova)))
return 0;
 
-   unmapped = __arm_v7s_unmap(data, iova, size, 1, data->pgd);
-   if (unmapped)
-   io_pgtable_tlb_sync(>iop);
+   return __arm_v7s_unmap(data, iova, size, 1, data->pgd);
+}
+
+static void arm_v7s_iotlb_sync(struct io_pgtable_ops *ops)
+{
+   struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
 
-   return unmapped;
+   io_pgtable_tlb_sync(>iop);
 }
 
 static phys_addr_t arm_v7s_iova_to_phys(struct io_pgtable_ops *ops,
@@ -734,6 +739,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct 
io_pgtable_cfg *cfg,
data->iop.ops = (struct io_pgtable_ops) {
.map= arm_v7s_map,
.unmap  = arm_v7s_unmap,
+   .iotlb_sync = arm_v7s_iotlb_sync,
.iova_to_phys   = arm_v7s_iova_to_phys,
};
 
@@ -832,7 +838,7 @@ static int __init arm_v7s_do_selftests(void)
.quirks = IO_PGTABLE_QUIRK_ARM_NS | IO_PGTABLE_QUIRK_NO_DMA,
.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M,
};
-   unsigned int iova, size, iova_start;
+   unsigned int iova, size, unmapped, iova_start;
unsigned int i, 

[PATCH v2 2/3] iommu/arm-smmu-v3: add support for unmap an iova range with only one tlb sync

[Zhen Lei]

This patch is base on: 
(add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing")

Because iotlb_sync is moved out of ".unmap = arm_smmu_unmap", some interval
".unmap" calls should explicitly followed by a iotlb_sync operation.

Signed-off-by: Zhen Lei 
---
 drivers/iommu/arm-smmu-v3.c| 10 ++
 drivers/iommu/io-pgtable-arm.c | 30 --
 drivers/iommu/io-pgtable.h |  1 +
 3 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index ef42c4b..e92828e 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1772,6 +1772,15 @@ arm_smmu_unmap(struct iommu_domain *domain, unsigned 
long iova, size_t size)
return ops->unmap(ops, iova, size);
 }
 
+static void arm_smmu_iotlb_sync(struct iommu_domain *domain)
+{
+   struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+   struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops;
+
+   if (ops && ops->iotlb_sync)
+   ops->iotlb_sync(ops);
+}
+
 static phys_addr_t
 arm_smmu_iova_to_phys(struct iommu_domain *domain, dma_addr_t iova)
 {
@@ -1991,6 +2000,7 @@ static struct iommu_ops arm_smmu_ops = {
.attach_dev = arm_smmu_attach_dev,
.map= arm_smmu_map,
.unmap  = arm_smmu_unmap,
+   .iotlb_sync = arm_smmu_iotlb_sync,
.map_sg = default_iommu_map_sg,
.iova_to_phys   = arm_smmu_iova_to_phys,
.add_device = arm_smmu_add_device,
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index e8018a3..805efc9 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -304,6 +304,8 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable 
*data,
WARN_ON(!selftest_running);
return -EEXIST;
} else if (iopte_type(pte, lvl) == ARM_LPAE_PTE_TYPE_TABLE) {
+   size_t unmapped;
+
/*
 * We need to unmap and free the old table before
 * overwriting it with a block entry.
@@ -312,7 +314,9 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable 
*data,
size_t sz = ARM_LPAE_BLOCK_SIZE(lvl, data);
 
tblp = ptep - ARM_LPAE_LVL_IDX(iova, lvl, data);
-   if (WARN_ON(__arm_lpae_unmap(data, iova, sz, lvl, tblp) != sz))
+   unmapped = __arm_lpae_unmap(data, iova, sz, lvl, tblp);
+   io_pgtable_tlb_sync(>iop);
+   if (WARN_ON(unmapped != sz))
return -EINVAL;
}
 
@@ -584,7 +588,6 @@ static int __arm_lpae_unmap(struct arm_lpae_io_pgtable 
*data,
/* Also flush any partial walks */
io_pgtable_tlb_add_flush(iop, iova, size,
ARM_LPAE_GRANULE(data), false);
-   io_pgtable_tlb_sync(iop);
ptep = iopte_deref(pte, data);
__arm_lpae_free_pgtable(data, lvl + 1, ptep);
} else {
@@ -609,7 +612,6 @@ static int __arm_lpae_unmap(struct arm_lpae_io_pgtable 
*data,
 static int arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
  size_t size)
 {
-   size_t unmapped;
struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
arm_lpae_iopte *ptep = data->pgd;
int lvl = ARM_LPAE_START_LVL(data);
@@ -617,11 +619,14 @@ static int arm_lpae_unmap(struct io_pgtable_ops *ops, 
unsigned long iova,
if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
return 0;
 
-   unmapped = __arm_lpae_unmap(data, iova, size, lvl, ptep);
-   if (unmapped)
-   io_pgtable_tlb_sync(>iop);
+   return __arm_lpae_unmap(data, iova, size, lvl, ptep);
+}
+
+static void arm_lpae_iotlb_sync(struct io_pgtable_ops *ops)
+{
+   struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
 
-   return unmapped;
+   io_pgtable_tlb_sync(>iop);
 }
 
 static phys_addr_t arm_lpae_iova_to_phys(struct io_pgtable_ops *ops,
@@ -734,6 +739,7 @@ arm_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg)
data->iop.ops = (struct io_pgtable_ops) {
.map= arm_lpae_map,
.unmap  = arm_lpae_unmap,
+   .iotlb_sync = arm_lpae_iotlb_sync,
.iova_to_phys   = arm_lpae_iova_to_phys,
};
 
@@ -1030,7 +1036,7 @@ static int __init arm_lpae_run_tests(struct 
io_pgtable_cfg *cfg)
 
int i, j;
unsigned long iova;
-   size_t size;
+   size_t size, unmapped;
struct io_pgtable_ops *ops;
 
selftest_running = true;
@@ -1082,7 +1088,9 @@ static int __init arm_lpae_run_tests(struct 
io_pgtable_cfg *cfg)
 
/* Partial unmap */
size = 

[PATCH v2 0/3] arm-smmu: performance optimization

[Zhen Lei]

v1 -> v2:
base on (add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing")

Zhen Lei (3):
  iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock
confliction
  iommu/arm-smmu-v3: add support for unmap an iova range with only one
tlb sync
  iommu/arm-smmu: add support for unmap a memory range with only one tlb
sync

 drivers/iommu/arm-smmu-v3.c| 52 ++
 drivers/iommu/arm-smmu.c   | 10 
 drivers/iommu/io-pgtable-arm-v7s.c | 32 +++
 drivers/iommu/io-pgtable-arm.c | 30 ++
 drivers/iommu/io-pgtable.h |  1 +
 5 files changed, 99 insertions(+), 26 deletions(-)

-- 
2.5.0


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[RFC PATCH 1/1] iommu/arm-smmu: Add support for multiple TBU child devices

[Vivek Gautam]

ARM MMU-500 implements a TBU (uTLB) for each connected master
besides a single TCU which controls and manages the address
translations. Each of these TBUs can either be in the same
power domain as the master, or they can have a independent
power switch.
This design addresses the challenges to control TBU power.
Adding child devices for each TBUs present in the configuration
lets us control the power and clocks to TLBs having individual
power domains. The device link between master devices (such as,
display, and GPU) and TBU devices ensures that the master takes
care of powering the smmu as long as it's available.
When the master is not available, the TBUs are identified with
sid and powered on.

Signed-off-by: Vivek Gautam 
---

 - The idea behind this patch is to handle the distributed smmu
   architectures, similar to MMU-500.
 - Untested yet.
 - There are still few instances where the correct tbu device has
   to be referenced and thus powered on to handle TLB maintenance
   operations.

 .../devicetree/bindings/iommu/arm,smmu.txt |  27 +++
 drivers/iommu/arm-smmu.c   | 191 +++--
 2 files changed, 205 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index d97a6bc8e608..7cf67e75022e 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -98,6 +98,18 @@ conditions.
   accessed before master gets enabled and linked to its
   SMMU.
 
+- child nodes:ARM MMU-500 implements a TBU (page table cache or TLB) for
+  each connected master besides a single TCU that controls
+  and manages the address translations.
+  Each of the child nodes represents a TBU that is attached to
+  the master. This child node will have following property:
+
+  - compatibe:   must be "arm,mmu-500-tbu" for TBU child nodes of 
arm,mmu-500
+ smmu.
+  - stream-id-range: array representing the starting stream id and the number
+ of supported stream-ids. This gives information about
+ the range of stream-ids that are supported by this TBU.
+
 ** Deprecated properties:
 
 - mmu-masters (deprecated in favour of the generic "iommus" binding) :
@@ -187,3 +199,18 @@ conditions.
 < SMMU_MDP_AHB_CLK>;
clock-names = "bus", "iface";
};
+
+   smmu4: iommu {
+   compatible = "arm,mmu-500";
+   reg = <0xd0 0x1>;
+...
+...
+#address-cells = <1>;
+#size-cells = <0>;
+
+tbu: tbu@0 {
+ compatible = "arm,mmu-500-tbu";
+ reg = <0>;
+ stream-id-range = <0x0 0x400>;
+};
+};
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 14137e389071..ba84693e2de3 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -224,6 +224,8 @@ struct arm_smmu_device {
 
/* IOMMU core code handle */
struct iommu_device iommu;
+
+   struct list_headtbu_list;
 };
 
 enum arm_smmu_context_fmt {
@@ -333,6 +335,33 @@ static int __find_legacy_master_phandle(struct device 
*dev, void *data)
 static struct platform_driver arm_smmu_driver;
 static struct iommu_ops arm_smmu_ops;
 
+struct arm_smmu500_tbu {
+   struct device *dev;
+   u32 sid_range[2];
+   struct list_head list;
+   struct arm_smmu_device *smmu;
+};
+
+static struct device *find_tbu(struct device *parent, u16 sid)
+{
+   struct arm_smmu_device *smmu = dev_get_drvdata(parent);
+   struct arm_smmu500_tbu *tbu;
+   u32 start, end;
+   struct device *dev = NULL;
+
+   list_for_each_entry(tbu, >tbu_list, list) {
+   start = tbu->sid_range[0];
+   end = start + tbu->sid_range[1];
+
+   if (start <= sid && sid < end) {
+   dev = tbu->dev;
+   break;
+   }
+   }
+
+   return dev;
+}
+
 static int arm_smmu_register_legacy_master(struct device *dev,
   struct arm_smmu_device **smmu)
 {
@@ -927,6 +956,7 @@ static void arm_smmu_destroy_domain_context(struct 
iommu_domain *domain)
if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
return;
 
+   /* TODO Get the TBU dev power it on; or turn on all the TBUs? */
ret = pm_runtime_get_sync(smmu->dev);
if (ret)
return;
@@ -1379,6 +1409,8 @@ static int arm_smmu_add_device(struct device *dev)
struct iommu_fwspec *fwspec = dev->iommu_fwspec;
struct device_link *link;
int i, ret;
+   u16 sid;
+   

Re: [v4,0/3] iommu/ipmmu-vmsa: r8a7796 support V4

[Oleksandr]

Hi, all.

Gentle reminder.

On 05.09.17 19:52, Oleksandr wrote:


Hi, Magnus, maintainers, all.

On 19.06.17 14:04, Magnus Damm wrote:

iommu/ipmmu-vmsa: r8a7796 support V4

[PATCH v4 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
[PATCH v4 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
[PATCH v4 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code

This series adds r8a7796 support to the IPMMU driver. The DT binding
gets updated, maximum number of micro-TLBs are increased and the
driver is adjusted to match on the new DT binding.

I am interested in adding IPMMU-VMSA support to Xen hypervisor.

I did some preparations for making IPMMU-VMSA to feel comfortable [1] 
inside Xen
followed by direct porting Linux IPMMU-VMSA driver and ARM LPAE 
page-table allocator [2] to it.


I decided to base on the "BSP" driver [3] because it had more complete 
support than the "mainline" one [4].


During review I got a feedback that "BSP" driver wasn't the best 
choice to be ported.
Xen ARM maintainers worry about "BSP" driver which haven't had a 
thorough review by the Linux community and as the result might have 
bugs which will never be fixed, etc.


So, for the IPMMU-VMSA support to be accepted by Xen community I 
should either write our own driver based on BSP/mainline/whatever 
which contains only relevant to Xen things or
direct port from "mainline" driver. As the second option relies on the 
required support [5] which isn't in mainline yet, it is not clear when 
this support gets merged and how it will be modified/reworked before,
we preliminarily decided to follow the first option. But, I would like 
to consider second option again. Despite the complexity of second 
option, it has one significant benefit.


I see that Linux driver is being developed quite actively and looking 
over all related patch series I got a feeling that required support 
was about to reach upstream.


Could you, please, clarify some questions which, I hope, help us to 
make a decision:

1. Do you have approximate time-frame for getting this support in?
2. Are fundamental/significant changes planned for this support?

Also, may I ask for a link to github branch which contains current 
(and likely r8a7795 and 32-bit ARM update) patch series?


Thank you in advance!

And sorry for the most likely incorrect format of this email.

[1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg115901.html
[2] https://lists.xen.org/archives/html/xen-devel/2017-07/msg02679.html
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/drivers/iommu/ipmmu-vmsa.c?h=v4.9/rcar-3.5.3
[4] 
http://elixir.free-electrons.com/linux/latest/source/drivers/iommu/ipmmu-vmsa.c
[5] 
https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022567.html

https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022577.html
https://lkml.org/lkml/2017/7/17/393


Changes since V3:
  - Rebased on top of [PATCH v4 00/09] iommu/ipmmu-vmsa: r8a7795 
support V4

  - Patch 3/3 updated with Reviewed-by - thanks Geert!

Changes since V2:
  - Patch 2/3 updated with an outer set of () - thanks Ramesh!
  - Patch 2/3 updated with Reviewed-by - thanks Geert!
  - Patch 3/3 updated to include white list support

Changes since V1:
  - Patch 1/3 updated with more Acked-by tags
  - Patch 2/3 updated with high I/O register range support

Patch 1/3 is ready for upstream merge and includes the following tags:
Signed-off-by: Magnus Damm 
Acked-by: Laurent Pinchart 
Acked-by: Rob Herring 
Acked-by: Simon Horman 
Acked-by: Geert Uytterhoeven 

Patch 2/3 and 3/3 are quite trivial but have no acked-by so far.

Signed-off-by: Magnus Damm 
---

  Developed on top of next-20170614 with the following series applied
  [PATCH 00/04] iommu/ipmmu-vmsa: 32-bit ARM update
  [PATCH v4 00/09] iommu/ipmmu-vmsa: r8a7795 support V4

  Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt |1
  drivers/iommu/ipmmu-vmsa.c |   24 +++---
  2 files changed, 18 insertions(+), 7 deletions(-)




___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH] iommu/amd: flush IOTLB for specific domains only (v3)

[Nath, Arindam]

Hi Daniel,

>-Original Message-
>From: Daniel Drake [mailto:dr...@endlessm.com]
>Sent: Tuesday, September 12, 2017 12:20 PM
>To: Nath, Arindam 
>Cc: Joerg Roedel ; Lendacky, Thomas
>; iommu@lists.linux-foundation.org; amd-
>g...@lists.freedesktop.org; Deucher, Alexander
>; Bridgman, John
>; Suthikulpanit, Suravee
>; li...@endlessm.com; Craig Stein
>; mic...@daenzer.net; Kuehling, Felix
>; sta...@vger.kernel.org
>Subject: Re: [PATCH] iommu/amd: flush IOTLB for specific domains only (v3)
>
>Hi,
>
>On Tue, May 30, 2017 at 3:38 PM, Nath, Arindam 
>wrote:
>>>-Original Message-
>>>From: Joerg Roedel [mailto:j...@8bytes.org]
>>>Sent: Monday, May 29, 2017 8:09 PM
>>>To: Nath, Arindam ; Lendacky, Thomas
>>>
>>>Cc: iommu@lists.linux-foundation.org; amd-...@lists.freedesktop.org;
>>>Deucher, Alexander ; Bridgman, John
>>>; dr...@endlessm.com; Suthikulpanit,
>Suravee
>>>; li...@endlessm.com; Craig Stein
>>>; mic...@daenzer.net; Kuehling, Felix
>>>; sta...@vger.kernel.org
>>>Subject: Re: [PATCH] iommu/amd: flush IOTLB for specific domains only
>(v3)
>>>
>>>Hi Arindam,
>>>
>>>I met Tom Lendacky last week in Nuremberg last week and he told me he is
>>>working on the same area of the code that this patch is for. His reason
>>>for touching this code was to solve some locking problems. Maybe you two
>>>can work together on a joint approach to improve this?
>>
>> Sure Joerg, I will work with Tom.
>
>What was the end result here? I see that the code has been reworked in
>4.13 so your original patch no longer applies. Is the reworked version
>also expected to solve the original issue?

Yes, if the reworked patch resolves the issue, my patch won't be required 
anymore.

Thanks,
Arindam

>
>Thanks
>Daniel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/amd: flush IOTLB for specific domains only (v3)

[Daniel Drake]

Hi,

On Tue, May 30, 2017 at 3:38 PM, Nath, Arindam  wrote:
>>-Original Message-
>>From: Joerg Roedel [mailto:j...@8bytes.org]
>>Sent: Monday, May 29, 2017 8:09 PM
>>To: Nath, Arindam ; Lendacky, Thomas
>>
>>Cc: iommu@lists.linux-foundation.org; amd-...@lists.freedesktop.org;
>>Deucher, Alexander ; Bridgman, John
>>; dr...@endlessm.com; Suthikulpanit, Suravee
>>; li...@endlessm.com; Craig Stein
>>; mic...@daenzer.net; Kuehling, Felix
>>; sta...@vger.kernel.org
>>Subject: Re: [PATCH] iommu/amd: flush IOTLB for specific domains only (v3)
>>
>>Hi Arindam,
>>
>>I met Tom Lendacky last week in Nuremberg last week and he told me he is
>>working on the same area of the code that this patch is for. His reason
>>for touching this code was to solve some locking problems. Maybe you two
>>can work together on a joint approach to improve this?
>
> Sure Joerg, I will work with Tom.

What was the end result here? I see that the code has been reworked in
4.13 so your original patch no longer applies. Is the reworked version
also expected to solve the original issue?

Thanks
Daniel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu