Hi Baolu,
On Wed, May 25, 2022 at 09:40:26AM +0800, Baolu Lu wrote:
> How do you like it? If you agree, I can queue it in my next pull request
> for fixes.
Would it help to tie DMAR and IOMMU components together, so that
selecting DMAR for IRQ remapping also selects IOMMU? The IOMMU can be in
PT
On Fri, Jun 24, 2022 at 01:38:58PM +0800, Yong Wu wrote:
> > > > diff --git a/drivers/iommu/mtk_iommu_v1.c
> > > > b/drivers/iommu/mtk_iommu_v1.c
> > > > index e1cb51b9866c..5386d889429d 100644
> > > > --- a/drivers/iommu/mtk_iommu_v1.c
> > > > +++ b/drivers/iommu/mtk_iommu_v1.c
> > > > @@ -304,7
On Thu, 2022-06-23 at 19:44 -0700, Nicolin Chen wrote:
> On Fri, Jun 24, 2022 at 09:35:49AM +0800, Baolu Lu wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On 2022/6/24 04:00, Nicolin Chen wrote:
> > > diff --git a/drivers/iommu/mtk_iommu_v1.c
> > >
On Fri, Jun 24, 2022 at 09:35:49AM +0800, Baolu Lu wrote:
> External email: Use caution opening links or attachments
>
>
> On 2022/6/24 04:00, Nicolin Chen wrote:
> > diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
> > index e1cb51b9866c..5386d889429d 100644
> > ---
On Wed, Jun 22, 2022 at 01:04:11PM +0100, Robin Murphy wrote:
> +struct vfio_device *vfio_device_get_from_iommu(struct iommu_group
> *iommu_group)
> +{
> + struct vfio_group *group = vfio_group_get_from_iommu(iommu_group);
> + struct vfio_device *device;
> +
> +
On 2022/6/24 04:00, Nicolin Chen wrote:
From: Jason Gunthorpe
The KVM mechanism for controlling wbinvd is based on OR of the coherency
property of all devices attached to a guest, no matter whether those
devices are attached to a single domain or multiple domains.
On the other hand, the
On Thu, Jun 23, 2022 at 05:00:44PM -0600, Alex Williamson wrote:
> > >> +struct vfio_device *vfio_device_get_from_iommu(struct iommu_group
> > >> *iommu_group)
> > >> +{
> > >> +struct vfio_group *group =
> > >> vfio_group_get_from_iommu(iommu_group);
> > >> +struct vfio_device
On 2022/6/24 09:14, Jerry Snitselaar wrote:
On Fri, Jun 24, 2022 at 08:55:08AM +0800, Baolu Lu wrote:
On 2022/6/24 01:02, Jerry Snitselaar wrote:
Hi Baolu & Dave,
I noticed last night that on a Sapphire Rapids system if you boot without
intel_iommu=on, the idxd driver will crash during probe
On 2022/6/24 04:00, Nicolin Chen wrote:
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index e1cb51b9866c..5386d889429d 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -304,7 +304,7 @@ static int mtk_iommu_v1_attach_device(struct
On Fri, Jun 24, 2022 at 08:55:08AM +0800, Baolu Lu wrote:
> On 2022/6/24 01:02, Jerry Snitselaar wrote:
> > Hi Baolu & Dave,
> >
> > I noticed last night that on a Sapphire Rapids system if you boot without
> > intel_iommu=on, the idxd driver will crash during probe in
> >
On 2022/6/24 01:02, Jerry Snitselaar wrote:
Hi Baolu & Dave,
I noticed last night that on a Sapphire Rapids system if you boot without
intel_iommu=on, the idxd driver will crash during probe in
iommu_sva_bind_device().
Should there be a sanity check before calling dev_iommu_ops(), or is the
On Thu, Jun 23, 2022 at 1:37 PM sascha hauer wrote:
>
> On Thu, Jun 23, 2022 at 10:26:46AM -0700, Saravana Kannan wrote:
> > On Thu, Jun 23, 2022 at 3:05 AM sascha hauer wrote:
> > >
> > > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
> > > > Commit 71066545b48e ("driver core:
On Thu, 23 Jun 2022 13:23:05 +0100
Robin Murphy wrote:
> On 2022-06-22 23:17, Alex Williamson wrote:
> > On Wed, 22 Jun 2022 13:04:11 +0100
> > Robin Murphy wrote:
> >
> >> Since IOMMU groups are mandatory for drivers to support, it stands to
> >> reason that any device which has been
On Thu, Jun 23, 2022 at 01:23:05PM +0100, Robin Murphy wrote:
> So yes, technically we could implement an iommu_group_capable() and an
> iommu_group_domain_alloc(), which would still just internally resolve the
> IOMMU ops and instance data from a member device to perform the driver-level
> call,
On Thu, Jun 23, 2022 at 10:26:46AM -0700, Saravana Kannan wrote:
> On Thu, Jun 23, 2022 at 3:05 AM sascha hauer wrote:
> >
> > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
> > > Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> > > enabled iommus and
On Thu, 23 Jun 2022 08:46:45 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, June 23, 2022 6:17 AM
> >
> > >
> > > ret = -EIO;
> > > - domain->domain = iommu_domain_alloc(bus);
> > > + domain->domain = iommu_domain_alloc(iommu_api_dev->dev-
> > >bus);
> >
> > It
The domain->ops validation was added, as a precaution, for mixed-driver
systems.
Per Robin's remarks,
* While bus_set_iommu() still exists, the core code prevents multiple
drivers from registering, so we can't really run into a situation of
having a mixed-driver system:
All devices in emulated_iommu_groups have pinned_page_dirty_scope
set, so the update_dirty_scope in the first list_for_each_entry
is always false. Clean it up, and move the "if update_dirty_scope"
part from the detach_group_done routine to the domain_list part.
Suggested-by: Jason Gunthorpe
Un-inline the domain specific logic from the attach/detach_group ops into
two paired functions vfio_iommu_alloc_attach_domain() and
vfio_iommu_detach_destroy_domain() that strictly deal with creating and
destroying struct vfio_domains.
Add the logic to check for EMEDIUMTYPE return code of
From: Jason Gunthorpe
The KVM mechanism for controlling wbinvd is based on OR of the coherency
property of all devices attached to a guest, no matter whether those
devices are attached to a single domain or multiple domains.
On the other hand, the benefit to using separate domains was that
Cases like VFIO wish to attach a device to an existing domain that was
not allocated specifically from the device. This raises a condition
where the IOMMU driver can fail the domain attach because the domain and
device are incompatible with each other.
This is a soft failure that can be resolved
This is a preparatory series for IOMMUFD v2 patches. It enforces error
code -EMEDIUMTYPE in iommu_attach_device() and iommu_attach_group() when
an IOMMU domain and a device/group are incompatible. It also drops the
useless domain->ops check since it won't fail in current environment.
These allow
Hello Saravana,
On 23.06.22 19:26, Saravana Kannan wrote:
> On Thu, Jun 23, 2022 at 3:05 AM sascha hauer wrote:
>>
>> On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
>>> Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
>>> enabled iommus and dmas
On Thu, Jun 23, 2022 at 10:36 AM Ahmad Fatoum wrote:
>
> Hello Saravana,
>
> On 23.06.22 19:26, Saravana Kannan wrote:
> > On Thu, Jun 23, 2022 at 3:05 AM sascha hauer wrote:
> >>
> >> On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
> >>> Commit 71066545b48e ("driver core: Set
On Thu, Jun 23, 2022 at 9:39 AM Andy Shevchenko
wrote:
>
> On Thu, Jun 23, 2022 at 12:04:21PM +0200, sascha hauer wrote:
> > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
>
> ...
>
> > I wonder if it wouldn't be a better approach to just probe all devices
> > and record the
On Thu, Jun 23, 2022 at 3:05 AM sascha hauer wrote:
>
> On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
> > Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> > enabled iommus and dmas dependency enforcement by default. On some
> > systems, this caused the
On Thu, Jun 23, 2022 at 6:39 PM Andy Shevchenko
wrote:
>
> On Thu, Jun 23, 2022 at 12:04:21PM +0200, sascha hauer wrote:
> > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
>
> ...
>
> > I wonder if it wouldn't be a better approach to just probe all devices
> > and record the
Hi Baolu & Dave,
I noticed last night that on a Sapphire Rapids system if you boot without
intel_iommu=on, the idxd driver will crash during probe in
iommu_sva_bind_device().
Should there be a sanity check before calling dev_iommu_ops(), or is the
expectation
that the caller would verify it is
On Thu, Jun 23, 2022 at 12:04:21PM +0200, sascha hauer wrote:
> On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
...
> I wonder if it wouldn't be a better approach to just probe all devices
> and record the device(node) they are waiting on. Then you know that you
> don't need to
On Tue, Jun 14, 2022 at 10:30:20AM +0200, Jörg Rödel wrote:
> Hi all,
>
> after several problems with the current IOMMU mailing list (no DKIM
> support, poor b4 interoperability) we have decided to move the IOMMU
> development discussions to a new list hosted at lists.linux.dev.
>
> The new list
On 6/22/2022 6:54 PM, Christoph Hellwig wrote:
Thanks,
this looks pretty good to me. A few comments below:
Thanks for your review.
On Fri, Jun 17, 2022 at 10:47:41AM -0400, Tianyu Lan wrote:
+/**
+ * struct io_tlb_area - IO TLB memory area descriptor
+ *
+ * This is a single area with a
On Tue, Jun 21, 2022 at 11:56 PM Khalid Aziz wrote:
> > while ((comp_code = next_inbox->comp_code) != BLOGIC_INBOX_FREE) {
> > - /*
> > -We are only allowed to do this because we limit our
> > -architectures we run on to machines where
On Thu, Jun 23, 2022 at 07:00:58AM +, Dexuan Cui wrote:
> It looks like commit 4a37f3dd9a831 fixed a different issue?
>
> Here my patch is for the latest mainline:
>
> In dma_direct_alloc()'s error handling path, we pass 'size' to
> dma_set_encrypted():
> out_encrypt_pages:
> if
Hi Marek,
On Thu, 23 Jun 2022 at 12:36, Marek Szyprowski wrote:
>
> PAGE_{SIZE,SHIFT} macros depend on the configured kernel's page size, but
> the driver expects values calculated as for 4KB pages. Fix this.
>
> Reported-by: Robin Murphy
> Signed-off-by: Marek Szyprowski
> ---
Reviewed-by:
On 2022-06-22 23:17, Alex Williamson wrote:
On Wed, 22 Jun 2022 13:04:11 +0100
Robin Murphy wrote:
Since IOMMU groups are mandatory for drivers to support, it stands to
reason that any device which has been successfully be added to a group
s/be //
Oops.
must be on a bus supported by
On 23/06/2022 11:36, Marek Szyprowski wrote:
> PAGE_{SIZE,SHIFT} macros depend on the configured kernel's page size, but
> the driver expects values calculated as for 4KB pages. Fix this.
>
> Reported-by: Robin Murphy
> Signed-off-by: Marek Szyprowski
> ---
> Untested, because Exynos based
Hi,
Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren:
> Hi,
>
> * Saravana Kannan [700101 02:00]:
> > Now that fw_devlink=on by default and fw_devlink supports
> > "power-domains" property, the execution will never get to the point
> > where driver_deferred_probe_check_state() is
On 2022-06-23 12:33, Joerg Roedel wrote:
On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote:
Thanks for your bravery!
It already starts, with that patch I am getting:
xhci_hcd :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x000f address=0xff00ffefe000
On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote:
> Thanks for your bravery!
It already starts, with that patch I am getting:
xhci_hcd :02:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x000f address=0xff00ffefe000 flags=0x]
In my kernel log. The device is an
On Thu, Jun 23, 2022 at 10:42:52AM +0100, Robin Murphy wrote:
> TBH it's probably time to retire iommu_ops->pgsize_bitmap anyway. At the
> very least it would be logical to move it to iommu_domain_ops now, but maybe
> we could skip ahead and just rely on drivers initialising
>
On 2022-06-23 02:54, Yong Wu wrote:
On Thu, 2022-06-16 at 11:31 +0100, Robin Murphy wrote:
On 2022-06-16 11:08, Yong Wu wrote:
On Thu, 2022-06-16 at 09:59 +0100, Robin Murphy wrote:
On 2022-06-16 06:42, Yong Wu wrote:
The mtk_iommu_mm_dts_parse will parse the smi larbs nodes. if
the
i+1
larb
On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
> Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> enabled iommus and dmas dependency enforcement by default. On some
> systems, this caused the console device's probe to get delayed until the
>
On 2022-06-23 09:03, Joerg Roedel wrote:
On Fri, Jun 03, 2022 at 04:51:03PM +0530, Vasant Hegde wrote:
Fix below sparse warning:
CHECK drivers/iommu/amd/iommu.c
drivers/iommu/amd/iommu.c:73:24: warning: symbol 'amd_iommu_ops' was not
declared. Should it be static?
Also we are going to
PAGE_{SIZE,SHIFT} macros depend on the configured kernel's page size, but
the driver expects values calculated as for 4KB pages. Fix this.
Reported-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
Untested, because Exynos based boards I have doesn't boot with non-4KB
page size for other
On 2022-06-23 08:00, Dexuan Cui wrote:
From: Christoph Hellwig
Sent: Wednesday, June 22, 2022 10:44 PM
To: Dexuan Cui
...
On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
The third parameter of dma_set_encrypted() is a size in bytes rather than
the number of pages.
Fixes:
> From: Alex Williamson
> Sent: Thursday, June 23, 2022 6:17 AM
>
> >
> > ret = -EIO;
> > - domain->domain = iommu_domain_alloc(bus);
> > + domain->domain = iommu_domain_alloc(iommu_api_dev->dev-
> >bus);
>
> It makes sense to move away from a bus centric interface to iommu ops
> and I
On 14/06/2022 14:12, John Garry wrote:
On 06/06/2022 10:30, John Garry wrote:
Add the IOMMU callback for DMA mapping API dma_opt_mapping_size(), which
allows the drivers to know the optimal mapping limit and thus limit the
requested IOVA lengths.
This value is based on the IOVA rcache range
On 10/06/2022 16:37, John Garry via iommu wrote:
On 6/9/22 10:54, John Garry wrote:
ok, but do you have a system where the UFS host controller is behind
an IOMMU? I had the impression that UFS controllers would be mostly
found in embedded systems and IOMMUs are not as common on there.
On Wed, Jun 22, 2022 at 12:11:31PM -0500, Suravee Suthikulpanit wrote:
> bool amd_iommu_v2_supported(void)
> {
> - return amd_iommu_v2_present;
> + /*
> + * Since DTE[Mode]=0 is prohibited on SNP-enabled system
> + * (i.e. EFR[SNPSup]=1), IOMMUv2 page table cannot be used
On Wed, Jun 22, 2022 at 12:11:25PM -0500, Suravee Suthikulpanit wrote:
> #ifdef CONFIG_IRQ_REMAP
> +/*
> + * Iterate through all the IOMMUs to verify if the specified
> + * EFR bitmask of IOMMU feature are set.
> + * Warn and return false if found inconsistency.
> + */
> static bool
On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren wrote:
>
> * Saravana Kannan [220622 19:05]:
> > On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren wrote:
> > >
> > > Hi,
> > >
> > > * Saravana Kannan [220621 19:29]:
> > > > On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote:
> > > > >
> > > > >
On Fri, Jun 03, 2022 at 04:51:00PM +0530, Vasant Hegde wrote:
> - Part 1 (patch 1-4 and 6)
> Refactor the current IOMMU page table code to adopt the generic IO page
> table framework, and add AMD IOMMU Guest (v2) page table management code.
>
> - Part 2 (patch 5)
> Add support for the AMD
On Fri, Jun 03, 2022 at 04:51:07PM +0530, Vasant Hegde wrote:
> + amd_iommu_pgtable= [HW,X86-64]
> + Specifies one of the following AMD IOMMU page table to
> + be used for DMA remapping for DMA-API:
> + v1 - Use v1 page table
On Fri, Jun 03, 2022 at 04:51:04PM +0530, Vasant Hegde wrote:
> +/* Allocate page table */
> +static u64 *v2_alloc_pte(u64 *pgd, unsigned long iova,
> + unsigned long pg_size, bool *updated)
> +{
> + u64 *pte, *page;
> + int level, end_level;
> +
> +
Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
enabled iommus and dmas dependency enforcement by default. On some
systems, this caused the console device's probe to get delayed until the
deferred_probe_timeout expires.
We need consoles to work as soon as possible, so mark
When firmware sets the FWNODE_FLAG_BEST_EFFORT flag for a fwnode,
fw_devlink will do a best effort ordering for that device where it'll
only enforce the probe/suspend/resume ordering of that device with
suppliers that have drivers. The driver of that device can then decide
if it wants to defer
fw_devlink.strict=1 has been enabled by default. This was delaying the
probe of console devices. This series fixes that.
v1->v2:
- Added missing NULL check
- Added Tested-by tags
-Saravana
cc: sascha hauer
cc: peng fan
cc: kevin hilman
cc: ulf hansson
cc: len brown
cc: pavel machek
cc:
On Wed, Jun 22, 2022 at 11:50 PM Sascha Hauer wrote:
>
> On Wed, Jun 22, 2022 at 02:59:10PM -0700, Saravana Kannan wrote:
> > When firmware sets the FWNODE_FLAG_BEST_EFFORT flag for a fwnode,
> > fw_devlink will do a best effort ordering for that device where it'll
> > only enforce the
On Fri, Jun 03, 2022 at 04:51:03PM +0530, Vasant Hegde wrote:
> Fix below sparse warning:
> CHECK drivers/iommu/amd/iommu.c
> drivers/iommu/amd/iommu.c:73:24: warning: symbol 'amd_iommu_ops' was not
> declared. Should it be static?
>
> Also we are going to introduce v2 page table which has
Hi Vasant,
On Wed, May 11, 2022 at 12:51:06PM +0530, Vasant Hegde wrote:
> .../admin-guide/kernel-parameters.txt | 34 +-
> drivers/iommu/amd/amd_iommu.h | 13 +-
> drivers/iommu/amd/amd_iommu_types.h | 133 +++-
> drivers/iommu/amd/init.c
On Thu, Jun 23, 2022 at 03:50:22AM +, Tian, Kevin wrote:
> External email: Use caution opening links or attachments
>
>
> > From: Robin Murphy
> > Sent: Wednesday, June 22, 2022 3:55 PM
> >
> > On 2022-06-16 23:23, Nicolin Chen wrote:
> > > On Thu, Jun 16, 2022 at 06:40:14AM +, Tian,
On Wed, May 25, 2022 at 04:54:16PM +0200, Uros Bizjak wrote:
> Use try_cmpxchg64 instead of cmpxchg64 (*ptr, old, new) != old in
> alloc_pte and free_clear_pte. cmpxchg returns success in ZF flag, so this
> change saves a compare after cmpxchg (and related move instruction
> in front of cmpxchg).
Hi Matthias,
On Wed, Jun 22, 2022 at 04:12:47PM +0200, Matthias Brugger wrote:
> I wanted to check if you took also 3 and 4, as these should go through my
> tree. Unfortunately you haven't pushed your tree (yet). In case you took the
> whole series, can you please drop the dts patches. I'll apply
* Saravana Kannan [220622 19:05]:
> On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren wrote:
> >
> > Hi,
> >
> > * Saravana Kannan [220621 19:29]:
> > > On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote:
> > > >
> > > > Hi,
> > > >
> > > > * Saravana Kannan [700101 02:00]:
> > > > > Now that
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent device will encounter the "DMAR: Setup RID2PASID
failed" failure as the pasid entry has already been marked as present.
As the
> From: Christoph Hellwig
> Sent: Wednesday, June 22, 2022 10:44 PM
> To: Dexuan Cui
> ...
> On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> > The third parameter of dma_set_encrypted() is a size in bytes rather than
> > the number of pages.
> >
> > Fixes: 4d0564785bb0
On Wed, Jun 22, 2022 at 02:59:10PM -0700, Saravana Kannan wrote:
> When firmware sets the FWNODE_FLAG_BEST_EFFORT flag for a fwnode,
> fw_devlink will do a best effort ordering for that device where it'll
> only enforce the probe/suspend/resume ordering of that device with
> suppliers that have
On 5/26/2022 9:44 AM, Sai Prakash Ranjan wrote:
TLB sync timeouts can be due to various reasons such as TBU power down
or pending TCU/TBU invalidation/sync and so on. Debugging these often
require dumping of some implementation defined registers to know the
status of TBU/TCU operations and some
68 matches
Mail list logo
