On Mon, May 13, 2019 at 11:37 AM Jean-Philippe Brucker
wrote:
>
> Hi Rob,
>
> On 10/05/2019 19:23, Rob Clark wrote:
> > On Fri, Sep 22, 2017 at 2:58 AM Jean-Philippe Brucker
> > wrote:
> >>
> >> On 22/09/17 10:02, Joerg Roedel wrote:
> >>> On Tue, Sep 19, 2017 at 10:23:43AM -0400, Rob Clark
On Mon, 13 May 2019 18:09:48 +0100
Jean-Philippe Brucker wrote:
> On 13/05/2019 17:50, Auger Eric wrote:
> >> struct iommu_inv_pasid_info {
> >> #define IOMMU_INV_PASID_FLAGS_PASID(1 << 0)
> >> #define IOMMU_INV_PASID_FLAGS_ARCHID (1 << 1)
> >>__u32 flags;
> >>__u32
Hi Rob,
On 10/05/2019 19:23, Rob Clark wrote:
> On Fri, Sep 22, 2017 at 2:58 AM Jean-Philippe Brucker
> wrote:
>>
>> On 22/09/17 10:02, Joerg Roedel wrote:
>>> On Tue, Sep 19, 2017 at 10:23:43AM -0400, Rob Clark wrote:
I would like to decide in the IRQ whether or not to queue work or not,
On 13/05/2019 17:50, Auger Eric wrote:
>> struct iommu_inv_pasid_info {
>> #define IOMMU_INV_PASID_FLAGS_PASID (1 << 0)
>> #define IOMMU_INV_PASID_FLAGS_ARCHID (1 << 1)
>> __u32 flags;
>> __u32 archid;
>> __u64 pasid;
>> };
> I agree it does the job now. However it looks a
Hi Jacob,
On 5/13/19 6:41 PM, Jacob Pan wrote:
> On Mon, 13 May 2019 09:13:01 +0200
> Eric Auger wrote:
>
>> When reading the vtd specification and especially the
>> Reserved Memory Region Reporting Structure chapter,
>> it is not obvious a device scope element cannot be a
>> PCI-PCI bridge, in
Hi Jean-Philippe,
On 5/13/19 1:20 PM, Jean-Philippe Brucker wrote:
> Hi Eric,
>
> On 13/05/2019 10:14, Auger Eric wrote:
>> I noticed my qemu integration was currently incorrectly using PASID
>> invalidation for ASID based invalidation (SMMUV3 Stage1 CMD_TLBI_NH_ASID
>> invalidation command). So
On Mon, 13 May 2019 09:13:01 +0200
Eric Auger wrote:
> When reading the vtd specification and especially the
> Reserved Memory Region Reporting Structure chapter,
> it is not obvious a device scope element cannot be a
> PCI-PCI bridge, in which case all downstream ports are
> likely to access
Hi Robin,
On 5/13/19 1:43 PM, Robin Murphy wrote:
> On 10/05/2019 15:34, Auger Eric wrote:
>> Hi Robin,
>>
>> On 5/8/19 4:24 PM, Robin Murphy wrote:
>>> On 08/04/2019 13:19, Eric Auger wrote:
To allow nested stage support, we need to store both
stage 1 and stage 2 configurations (and
On 2019/5/8 17:42, John Garry wrote:
> On 18/04/2019 14:57, Zhen Lei wrote:
>> First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
>> opportunity to set {lazy|strict} mode as default at build time. Then put
>> the three config options in an choice, make people can only
Hi Robin,
On 5/13/19 4:01 PM, Robin Murphy wrote:
> On 13/05/2019 13:16, Auger Eric wrote:
>> Hi Robin,
>> On 5/8/19 5:01 PM, Robin Murphy wrote:
>>> On 08/04/2019 13:19, Eric Auger wrote:
Implement domain-selective and page-selective IOTLB invalidations.
Signed-off-by: Eric Auger
On 13/05/2019 13:16, Auger Eric wrote:
Hi Robin,
On 5/8/19 5:01 PM, Robin Murphy wrote:
On 08/04/2019 13:19, Eric Auger wrote:
Implement domain-selective and page-selective IOTLB invalidations.
Signed-off-by: Eric Auger
---
v6 -> v7
- check the uapi version
v3 -> v4:
- adapt to changes in
On 13/05/2019 13:32, Auger Eric wrote:
Hi Robin,
On 5/13/19 1:54 PM, Robin Murphy wrote:
On 13/05/2019 08:46, Auger Eric wrote:
Hi Robin,
On 5/8/19 7:20 PM, Robin Murphy wrote:
On 08/04/2019 13:19, Eric Auger wrote:
When a stage 1 related fault event is read from the event queue,
let's
The pull request you sent on Mon, 13 May 2019 13:53:34 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-updates-v5.2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a13f0655503a4a89df67fdc7cac6a7810795d4b3
Thank you!
--
On 13/05/2019 13:42, Jean-Philippe Brucker wrote:
On 13/05/2019 08:09, Pankaj Bansal wrote:
Hi Jean,
-Original Message-
From: Jean-Philippe Brucker
Sent: Friday, 10 May, 2019 07:07 PM
To: Pankaj Bansal ; Will Deacon
; Robin Murphy ; Joerg
Roedel
Cc: iommu@lists.linux-foundation.org;
Hi Pankaj,
> -Original Message-
> From: linux-arm-kernel On
> Behalf Of Pankaj Bansal
> Sent: Friday, May 10, 2019 3:34 PM
>
> Hi Will/Robin/Joerg,
>
> I am s/w engineer from NXP India Pvt. Ltd.
> We are using SMMU-V3 in one of NXP SOC.
> I have a question about the SMMU Stream ID
On 13/05/2019 08:09, Pankaj Bansal wrote:
> Hi Jean,
>
>> -Original Message-
>> From: Jean-Philippe Brucker
>> Sent: Friday, 10 May, 2019 07:07 PM
>> To: Pankaj Bansal ; Will Deacon
>> ; Robin Murphy ; Joerg
>> Roedel
>> Cc: iommu@lists.linux-foundation.org; Varun Sethi ; linux-
>>
Hi Robin,
On 5/13/19 1:54 PM, Robin Murphy wrote:
> On 13/05/2019 08:46, Auger Eric wrote:
>> Hi Robin,
>>
>> On 5/8/19 7:20 PM, Robin Murphy wrote:
>>> On 08/04/2019 13:19, Eric Auger wrote:
When a stage 1 related fault event is read from the event queue,
let's propagate it to potential
Hi Robin,
On 5/8/19 5:01 PM, Robin Murphy wrote:
> On 08/04/2019 13:19, Eric Auger wrote:
>> Implement domain-selective and page-selective IOTLB invalidations.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>> v6 -> v7
>> - check the uapi version
>>
>> v3 -> v4:
>> - adapt to changes in the uapi
>> -
On 10/05/2019 15:35, Auger Eric wrote:
Hi Robin,
On 5/8/19 4:38 PM, Robin Murphy wrote:
On 08/04/2019 13:19, Eric Auger wrote:
On attach_pasid_table() we program STE S1 related info set
by the guest into the actual physical STEs. At minimum
we need to program the context descriptor GPA and
On 13/05/2019 08:46, Auger Eric wrote:
Hi Robin,
On 5/8/19 7:20 PM, Robin Murphy wrote:
On 08/04/2019 13:19, Eric Auger wrote:
When a stage 1 related fault event is read from the event queue,
let's propagate it to potential external fault listeners, ie. users
who registered a fault handler.
Hi Linus,
this pull-request includes two reverts which I had to do after the merge
window started, because the reverted patches caused issues in
linux-next. But the rest of this was ready before the merge window. With
this in mind:
The following changes since commit
On 10/05/2019 15:34, Auger Eric wrote:
Hi Robin,
On 5/8/19 4:24 PM, Robin Murphy wrote:
On 08/04/2019 13:19, Eric Auger wrote:
To allow nested stage support, we need to store both
stage 1 and stage 2 configurations (and remove the former
union).
A nested setup is characterized by both s1_cfg
On 13/05/2019 11:04, Vivek Gautam wrote:
Few Qualcomm platforms such as, sdm845 have an additional outer
cache called as System cache, aka. Last level cache (LLC) that
allows non-coherent devices to upgrade to using caching.
This cache sits right before the DDR, and is tightly coupled
with the
Hi Eric,
On 13/05/2019 10:14, Auger Eric wrote:
> I noticed my qemu integration was currently incorrectly using PASID
> invalidation for ASID based invalidation (SMMUV3 Stage1 CMD_TLBI_NH_ASID
> invalidation command). So I think we also need ARCHID invalidation.
> Sorry for the late notice.
>>
Few Qualcomm platforms such as, sdm845 have an additional outer
cache called as System cache, aka. Last level cache (LLC) that
allows non-coherent devices to upgrade to using caching.
This cache sits right before the DDR, and is tightly coupled
with the memory controller. The clients using this
Hi Jacob, Jean-Philippe,
On 5/4/19 12:32 AM, Jacob Pan wrote:
> From: "Liu, Yi L"
>
> In any virtualization use case, when the first translation stage
> is "owned" by the guest OS, the host IOMMU driver has no knowledge
> of caching structure updates unless the guest invalidation activities
>
Hi Robin,
On 5/8/19 7:20 PM, Robin Murphy wrote:
> On 08/04/2019 13:19, Eric Auger wrote:
>> When a stage 1 related fault event is read from the event queue,
>> let's propagate it to potential external fault listeners, ie. users
>> who registered a fault handler.
>>
>> Signed-off-by: Eric Auger
When reading the vtd specification and especially the
Reserved Memory Region Reporting Structure chapter,
it is not obvious a device scope element cannot be a
PCI-PCI bridge, in which case all downstream ports are
likely to access the reserved memory region. Let's handle
this case in
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, April 24, 2019 10:55 PM
>
> Hi Jörg, Magnus,
>
> On R-Car Gen3 systems with PSCI, PSCI may power down the SoC during
> system suspend, thus losing all IOMMU state. Hence after s2ram, devices
> behind an IPMMU (e.g. SATA), and
Currently the Intel reserved region is attached to the
RMRR unit and when building the list of RMRR seen by a device
we link this unique reserved region without taking care of
potential multiple usage of this reserved region by several devices.
Also while reading the vtd spec it is unclear to me
intel_iommu_get_resv_regions() aims to return the list of
reserved regions accessible by a given @device. However several
devices can access the same reserved memory region and when
building the list it is not safe to use a single iommu_resv_region
object, whose container is the RMRR. This
We plan to call iommu_alloc_resv_region in a non preemptible section.
Pass a GFP flag to the function and update all the call sites.
Signed-off-by: Eric Auger
---
drivers/acpi/arm64/iort.c | 3 ++-
drivers/iommu/amd_iommu.c | 7 ---
drivers/iommu/arm-smmu-v3.c | 2 +-
In the case the RMRR device scope is a PCI-PCI bridge, let's check
the device belongs to the PCI sub-hierarchy.
Fixes: 0659b8dc45a6 ("iommu/vt-d: Implement reserved region get/put callbacks")
Signed-off-by: Eric Auger
---
drivers/iommu/intel-iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1
Hi Jean,
> -Original Message-
> From: Jean-Philippe Brucker
> Sent: Friday, 10 May, 2019 07:07 PM
> To: Pankaj Bansal ; Will Deacon
> ; Robin Murphy ; Joerg
> Roedel
> Cc: iommu@lists.linux-foundation.org; Varun Sethi ; linux-
> arm-ker...@lists.infradead.org; Nipun Gupta
> Subject:
On Mon, May 06, 2019 at 09:54:30AM +0800, Lu Baolu wrote:
> Agreed. I will prepare the next version simply without the optimization, so
> the offset is not required.
>
> For your changes in swiotlb, will you formalize them in patches or want
> me to do this?
Please do it yourself given that you
35 matches
Mail list logo
