On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote:
> On 2021-01-29 14:35, Will Deacon wrote:
> > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote:
> > > Add a new page protection flag IOMMU_LLC which can be used
> > > by non-coherent masters to set cacheable
On Sun, Jan 31, 2021 at 07:29:09PM +0100, Auger Eric wrote:
> Hi Jean,
>
> Some rather minor comments§questions below that may not justify a respin.
>
> On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote:
> > -static bool arm_smmu_iopf_supported(struct arm_smmu_master *master)
> > +bool
v4 --> v5:
1. Give up doing the mapping for the entire SMMU register space.
2. Fix some compile warnings. Sorry. So sorry.
v3 --> v4:
1. Delete the unnecessary encapsulation function
smmu_pmu_get_and_ioremap_resource().
2. Discard adding MODULE_SOFTDEP.
v2 --> v3:
Patch 3 is updated because
According to the SMMUv3 specification:
Each PMCG counter group is represented by one 4KB page (Page 0) with one
optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
DEFINED base addresses.
This means that the PMCG register spaces may be within the 64KB pages of
the SMMUv3
On 2021/2/1 19:14, Jean-Philippe Brucker wrote:
> Hi Zhou,
>
> On Mon, Feb 01, 2021 at 09:18:42AM +0800, Zhou Wang wrote:
>>> @@ -1033,8 +1076,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_domain
>>> *smmu_domain, int ssid,
>>> FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid) |
>>>
On 2021/2/1 20:54, Will Deacon wrote:
> On Sat, Jan 30, 2021 at 03:14:13PM +0800, Zhen Lei wrote:
>> According to the SMMUv3 specification:
>> Each PMCG counter group is represented by one 4KB page (Page 0) with one
>> optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
>>
Hi Jean,
On 2/1/21 12:12 PM, Jean-Philippe Brucker wrote:
> On Sun, Jan 31, 2021 at 07:29:09PM +0100, Auger Eric wrote:
>> Hi Jean,
>>
>> Some rather minor comments§questions below that may not justify a respin.
>>
>> On 1/27/21 4:43 PM, Jean-Philippe Brucker wrote:
>>> -static bool
The device iommu probe/attach might have failed leaving dev->iommu
to NULL and device drivers may still invoke these functions resulting
in a crash in iommu vendor driver code. Hence make sure we check that.
Also added iommu_ops to the "struct dev_iommu" and set it if the dev
is successfully
On Sat, Jan 30, 2021 at 03:14:13PM +0800, Zhen Lei wrote:
> According to the SMMUv3 specification:
> Each PMCG counter group is represented by one 4KB page (Page 0) with one
> optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
> DEFINED base addresses.
>
> This means that
On Mon, Feb 01, 2021 at 08:26:41PM +0800, Keqian Zhu wrote:
> > +static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
> > + struct arm_smmu_master *master)
> > +{
> > + int i;
> > + int ret = 0;
> > + struct arm_smmu_stream *new_stream, *cur_stream;
> >
On Thu, Jan 28, 2021 at 06:00:57PM +0100, Ricardo Ribalda wrote:
> > Given that we vmap the addresses this also needs
> > flush_kernel_vmap_range / invalidate_kernel_vmap_range calls for
> > VIVT architectures.
>
> We only read from the device to the cpu. Then can we run only
>
On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote:
>
> On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote:
> > On 2021-01-29 14:35, Will Deacon wrote:
> > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash Ranjan wrote:
> > > > Add a new page protection flag IOMMU_LLC which
On Mon, Jan 11, 2021 at 07:18:41PM +0800, Yong Wu wrote:
> This patch mainly adds support for mt8192 Multimedia IOMMU and SMI.
>
> mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> table format. The M4U-SMI HW diagram is as below:
>
> EMI
>
On Mon, Feb 01, 2021 at 02:16:16PM +0100, Auger Eric wrote:
> >>> + flt->type = IOMMU_FAULT_DMA_UNRECOV;
> >>> + flt->event = (struct iommu_fault_unrecoverable) {
> >>> + .reason = reason,
> >>> + .flags = IOMMU_FAULT_UNRECOV_ADDR_VALID |
> >>> +
Hi Joerg,
Please pull these Arm SMMU updates for 5.12. The biggest thing here isn't
actually Arm SMMU-related at all, but is the addition of a new driver for
the MT8192 IOMMU. I've included it here because it ended up touching
quite a bit of the io-pgtable code.
Please note that I've based this
On Mon, Feb 01, 2021 at 09:27:49PM +0800, Zhen Lei wrote:
> v4 --> v5:
> 1. Give up doing the mapping for the entire SMMU register space.
> 2. Fix some compile warnings. Sorry. So sorry.
That's alright, these things happen. However, this came in slightly too
late for 5.12, so please resend at
On 2021-01-29 11:45, Tomasz Figa wrote:
On Mon, Jan 25, 2021 at 4:34 PM Yong Wu wrote:
On Mon, 2021-01-25 at 13:18 +0900, Tomasz Figa wrote:
On Wed, Jan 20, 2021 at 4:08 PM Yong Wu wrote:
On Wed, 2021-01-20 at 13:15 +0900, Tomasz Figa wrote:
On Wed, Jan 13, 2021 at 3:45 PM Yong Wu
Hi Eric,
On 2020/11/18 19:21, Eric Auger wrote:
> In virtualization use case, when a guest is assigned
> a PCI host device, protected by a virtual IOMMU on the guest,
> the physical IOMMU must be programmed to be consistent with
> the guest mappings. If the physical IOMMU supports two
>
Hi Eric,
On 2020/11/18 19:21, Eric Auger wrote:
> On ARM, MSI are translated by the SMMU. An IOVA is allocated
> for each MSI doorbell. If both the host and the guest are exposed
> with SMMUs, we end up with 2 different IOVAs allocated by each.
> guest allocates an IOVA (gIOVA) to map onto the
On 2021/2/1 19:44, Robin Murphy wrote:
> On 2021-01-30 01:54, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/1/29 23:27, Robin Murphy wrote:
>>> On 2021-01-27 11:32, Zhen Lei wrote:
commit 52f3fab0067d ("iommu/arm-smmu-v3: Don't reserve implementation
defined register space") only
Hi Zhou,
On Mon, Feb 01, 2021 at 09:18:42AM +0800, Zhou Wang wrote:
> > @@ -1033,8 +1076,7 @@ int arm_smmu_write_ctx_desc(struct arm_smmu_domain
> > *smmu_domain, int ssid,
> > FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid) |
> > CTXDESC_CD_0_V;
> >
> > -
On 2021-01-30 07:14, Zhen Lei wrote:
According to the SMMUv3 specification:
Each PMCG counter group is represented by one 4KB page (Page 0) with one
optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION
DEFINED base addresses.
This means that the PMCG register spaces may be
Hi Eric,
On 2020/11/18 19:21, Eric Auger wrote:
> In true nested mode, both s1_cfg and s2_cfg will coexist.
> Let's remove the union and add a "set" field in each
> config structure telling whether the config is set and needs
> to be applied when writing the STE. In legacy nested mode,
> only the
On 2021-01-30 01:54, Leizhen (ThunderTown) wrote:
On 2021/1/29 23:27, Robin Murphy wrote:
On 2021-01-27 11:32, Zhen Lei wrote:
commit 52f3fab0067d ("iommu/arm-smmu-v3: Don't reserve implementation
defined register space") only reserves the basic SMMU register space. So
the ECMDQ register
Hi Eric,
On 2020/11/18 19:21, Eric Auger wrote:
> From: Jean-Philippe Brucker
>
> When handling faults from the event or PRI queue, we need to find the
> struct device associated to a SID. Add a rb_tree to keep track of SIDs.
>
> Signed-off-by: Jean-Philippe Brucker
[...]
> }
>
> +static
On Mon, Feb 01, 2021 at 10:30:17AM -0800, Jianxiong Gao wrote:
> NVMe driver relies on the address offset to function properly.
> This patch adds the offset preserve mask to NVMe driver when mapping
> via dma_map_sg_attrs and unmapping via nvme_unmap_sg. The mask
> depends on the page size defined
NVMe driver relies on the address offset to function properly.
This patch adds the offset preserve mask to NVMe driver when mapping
via dma_map_sg_attrs and unmapping via nvme_unmap_sg. The mask
depends on the page size defined by CC.MPS register of NVMe
controller.
Signed-off-by: Jianxiong Gao
For devices that need to preserve address offset on mapping through
swiotlb, this patch adds offset preserving based on page_offset_mask
and keeps the offset if the mask is non zero. This is needed for
device drivers like NVMe.
Signed-off-by: Jianxiong Gao
---
kernel/dma/swiotlb.c | 27
Some devices rely on the address offset in a page to function
correctly (NVMe driver as an example). These devices may use
a different page size than the Linux kernel. The address offset
has to be preserved upon mapping, and in order to do so, we
need to record the page_offset_mask first.
Hi Keqian,
On 2/1/21 12:27 PM, Keqian Zhu wrote:
> Hi Eric,
>
> On 2020/11/18 19:21, Eric Auger wrote:
>> In virtualization use case, when a guest is assigned
>> a PCI host device, protected by a virtual IOMMU on the guest,
>> the physical IOMMU must be programmed to be consistent with
>> the
NVMe driver and other applications may depend on the data offset
to operate correctly. Currently when unaligned data is mapped via
SWIOTLB, the data is mapped as slab aligned with the SWIOTLB. This
patch adds an option to make sure the mapped data preserves its
offset of the orginal addrss.
On Mon, Feb 1, 2021 at 10:56 AM Andy Shevchenko
wrote:
>
> On Mon, Feb 01, 2021 at 10:30:17AM -0800, Jianxiong Gao wrote:
> > NVMe driver relies on the address offset to function properly.
> > This patch adds the offset preserve mask to NVMe driver when mapping
> > via dma_map_sg_attrs and
From: Chunyan Zhang
This iommu module can be used by Unisoc's multimedia devices, such as
display, Image codec(jpeg) and a few signal processors, including
VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.
Signed-off-by: Chunyan Zhang
---
From: Chunyan Zhang
This iommu module can be used by Unisoc's multimedia devices, such as
display, Image codec(jpeg) and a few signal processors, including
VSP(video), GSP(graphic), ISP(image), and CPP(camera pixel processor), etc.
Signed-off-by: Chunyan Zhang
---
drivers/iommu/Kconfig |
From: Chunyan Zhang
Changes since v1:
* Fixed compile errors reported by kernel test robot .
* Changed to use syscon to get mapped registers for iommu and media devices to
avoid double map issue.
* Addressed Robin's comments:
- Added including offset in the returned physical address if the
Hi,
On Thu, Jan 7, 2021 at 4:31 AM Yong Wu wrote:
>
> @@ -2438,18 +2435,31 @@ static int __iommu_map(struct iommu_domain *domain,
> unsigned long iova,
> return ret;
> }
>
> +static int _iommu_map(struct iommu_domain *domain, unsigned long iova,
> + phys_addr_t
Could you please try the attached patch to see if the problem still persist.
Thanks,
Suravee
On 1/25/21 4:24 PM, Tj (Elloe Linux) wrote:
Lenovo E495 reports:
pci :00:00.2: AMD-Vi: Unable to read/write to IOMMU perf counter.
pci :00:00.2: can't derive routing for PCI INT A
pci
On 2021-02-01 23:50, Jordan Crouse wrote:
On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote:
>
> On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote:
> > On 2021-01-29 14:35, Will Deacon wrote:
> > > On Mon, Jan 11, 2021
Hi Jean,
On 2021/2/1 23:15, Jean-Philippe Brucker wrote:
> On Mon, Feb 01, 2021 at 08:26:41PM +0800, Keqian Zhu wrote:
>>> +static int arm_smmu_insert_master(struct arm_smmu_device *smmu,
>>> + struct arm_smmu_master *master)
>>> +{
>>> + int i;
>>> + int ret = 0;
Sleeping while atomic = bad. Let's fix an obvious typo to try to avoid it.
The warning that was seen (on a downstream kernel with the problematic
patch backported):
BUG: sleeping function called from invalid context at mm/page_alloc.c:4726
in_atomic(): 1, irqs_disabled(): 0, non_block: 0,
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: Tuesday, February 2, 2021 3:52 PM
> To: Jason Gunthorpe
> Cc: Song Bao Hua (Barry Song) ; chensihang (A)
> ; Arnd Bergmann ; Greg
> Kroah-Hartman ; linux-ker...@vger.kernel.org;
>
On 2/1/21 13:27, Jianxiong Gao wrote:
>> Why is this setting being done and undone on each IO? Wouldn't it be
>> more efficient to set it once during device initialization?
>>
>> And more importantly, this isn't thread safe: one CPU may be setting the
>> device's dma alignment mask to 0 while
On Mon, 2021-02-01 at 17:06 -0800, Douglas Anderson wrote:
> Sleeping while atomic = bad. Let's fix an obvious typo to try to avoid it.
>
> The warning that was seen (on a downstream kernel with the problematic
> patch backported):
>
> BUG: sleeping function called from invalid context at
On Mon, 2021-02-01 at 14:54 +, Will Deacon wrote:
> On Mon, Jan 11, 2021 at 07:18:41PM +0800, Yong Wu wrote:
> > This patch mainly adds support for mt8192 Multimedia IOMMU and SMI.
> >
> > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation
> > table format. The M4U-SMI
On 2021-02-01 23:50, Jordan Crouse wrote:
On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote:
>
> On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote:
> > On 2021-01-29 14:35, Will Deacon wrote:
> > > On Mon, Jan 11, 2021
Hi Eric,
On 2020/11/18 19:21, Eric Auger wrote:
> When nested stage translation is setup, both s1_cfg and
> s2_cfg are set.
>
> We introduce a new smmu domain abort field that will be set
> upon guest stage1 configuration passing.
>
> arm_smmu_write_strtab_ent() is modified to write both stage
Hi Eric,
On 2021/2/2 1:19, Auger Eric wrote:
> Hi Keqian,
>
> On 2/1/21 1:26 PM, Keqian Zhu wrote:
>> Hi Eric,
>>
>> On 2020/11/18 19:21, Eric Auger wrote:
>>> From: Jean-Philippe Brucker
>>>
>>> When handling faults from the event or PRI queue, we need to find the
>>> struct device associated
> -Original Message-
> From: Jason Gunthorpe [mailto:j...@ziepe.ca]
> Sent: Tuesday, February 2, 2021 12:44 PM
> To: Tian, Kevin
> Cc: Song Bao Hua (Barry Song) ; chensihang (A)
> ; Arnd Bergmann ; Greg
> Kroah-Hartman ; linux-ker...@vger.kernel.org;
> iommu@lists.linux-foundation.org;
From: Yian Chen
Software should parse every SATC table and all devices in the tables
reported by the BIOS and keep the information in kernel list for further
SATC policy deployment.
Signed-off-by: Yian Chen
---
drivers/iommu/intel/dmar.c | 9
drivers/iommu/intel/iommu.c | 89
From: Yian Chen
Starting from Intel Platform VT-d v3.2, BIOS may provide new remapping
structure SATC for SOC integrated devices, according to section 8.8 of
Intel VT-d architecture specification v3.2. The SATC structure reports
a list of the devices that require SATC enabling via ATS capacity.
Intel platform VT-d (v3.2) comes with a new type of DMAR subtable
SATC. The SATC table includes a list of SoC integrated devices
that require SATC. OS software can use this table to enable ATS
only for the devices in the list.
Yian Chen (3):
iommu/vt-d: Add new enum value and structure for SATC
From: Yian Chen
Starting from Intel VT-d v3.2, Intel platform BIOS can provide a new SATC
table structure. SATC table lists a set of SoC integrated devices that
require ATC to work (VT-d specification v3.2, section 8.8). Furthermore,
the new version of IOMMU supports SoC device ATS in both its
> Why is this setting being done and undone on each IO? Wouldn't it be
> more efficient to set it once during device initialization?
I agree that setting it once is the right way of doing it.
So I have changed the patch to enable the mask once in nvme_probe.
drivers/nvme/host/pci.c | 3 +++
1
> From: Jason Gunthorpe
> Sent: Tuesday, February 2, 2021 7:44 AM
>
> On Fri, Jan 29, 2021 at 10:09:03AM +, Tian, Kevin wrote:
> > > SVA is not doom to work with IO page fault only. If we have SVA+pin,
> > > we would get both sharing address and stable I/O latency.
> >
> > Isn't it like a
Hi Jean,
It seems that the preprocessing of the page faults(groups) here is relatively
generic, and if a device driver wants to reuse it while having its own
iopf_handle_single(),
is there any chance for this? :-)
Thanks,
Shenming
On 2021/1/27 23:43, Jean-Philippe Brucker wrote:
> Some systems
On 2021/2/1 23:50, Will Deacon wrote:
> On Mon, Feb 01, 2021 at 09:27:49PM +0800, Zhen Lei wrote:
>> v4 --> v5:
>> 1. Give up doing the mapping for the entire SMMU register space.
>> 2. Fix some compile warnings. Sorry. So sorry.
>
> That's alright, these things happen. However, this came in
On Mon, Feb 01, 2021 at 10:30:17AM -0800, Jianxiong Gao wrote:
> @@ -868,12 +871,24 @@ static blk_status_t nvme_map_data(struct nvme_dev *dev,
> struct request *req,
> if (!iod->nents)
> goto out_free_sg;
>
> + offset_ret = dma_set_min_align_mask(dev->dev,
>
> On Mon, Feb 01, 2021 at 10:30:17AM -0800, Jianxiong Gao wrote:
> > @@ -868,12 +871,24 @@ static blk_status_t nvme_map_data(struct nvme_dev
> *dev, struct request *req,
> > if (!iod->nents)
> > goto out_free_sg;
> >
> > + offset_ret = dma_set_min_align_mask(dev->dev,
> Why is this setting being done and undone on each IO? Wouldn't it be
> more efficient to set it once during device initialization?
>
> And more importantly, this isn't thread safe: one CPU may be setting the
> device's dma alignment mask to 0 while another CPU is expecting it to be
>
Hi Keqian,
On 2/1/21 1:26 PM, Keqian Zhu wrote:
> Hi Eric,
>
> On 2020/11/18 19:21, Eric Auger wrote:
>> From: Jean-Philippe Brucker
>>
>> When handling faults from the event or PRI queue, we need to find the
>> struct device associated to a SID. Add a rb_tree to keep track of SIDs.
>>
>>
> On Jan 28, 2021, at 9:52 AM, Chuck Lever wrote:
>
>
>
>> On Jan 28, 2021, at 8:59 AM, Robin Murphy wrote:
>>
>> On 2021-01-27 20:00, Chuck Lever wrote:
>>> Hi-
>>> This collection of patches seems to get the best throughtput results
>>> so far. The NFS WRITE result is fully restored,
On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
> On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote:
> >
> > On Fri, Jan 29, 2021 at 03:12:59PM +0530, Sai Prakash Ranjan wrote:
> > > On 2021-01-29 14:35, Will Deacon wrote:
> > > > On Mon, Jan 11, 2021 at 07:45:04PM +0530, Sai Prakash
On Fri, Jan 29, 2021 at 10:09:03AM +, Tian, Kevin wrote:
> > SVA is not doom to work with IO page fault only. If we have SVA+pin,
> > we would get both sharing address and stable I/O latency.
>
> Isn't it like a traditional MAP_DMA API (imply pinning) plus specifying
> cpu_va of the memory
63 matches
Mail list logo
