Hi Christoph,
On 2/14/22 3:38 PM, Christoph Hellwig wrote:
const struct iommu_ops intel_iommu_ops;
@@ -903,7 +905,8 @@ static void pgtable_walk(struct intel_iommu *iommu,
unsigned long pfn, u8 bus, u
struct dmar_domain *domain;
int offset, level;
- info =
Hi Jason,
On 2/14/22 10:00 PM, Jason Gunthorpe wrote:
+
+/* Convert device source ID into the index of device_domain_array. */
+static inline unsigned long devi_idx(unsigned long seg, u8 bus, u8 devfn)
+{
+ return (seg << 16) | PCI_DEVID(bus, devfn);
+}
/*
- * Iterate over elements
On 2/15/22 12:28 PM, Huang Adrian wrote:
On Tue, Feb 15, 2022 at 9:26 AM Lu Baolu wrote:
On 2/14/22 5:32 PM, Huang Adrian wrote:
Hi Baolu,
On Mon, Feb 14, 2022 at 8:35 AM Lu Baolu wrote:
Hi Adrian,
The solution is to prevent from allocating pasid table if those
devices are subdevices
On Tue, Feb 15, 2022 at 9:26 AM Lu Baolu wrote:
>
> On 2/14/22 5:32 PM, Huang Adrian wrote:
> > Hi Baolu,
> >
> > On Mon, Feb 14, 2022 at 8:35 AM Lu Baolu wrote:
> >>
> >> Hi Adrian,
> >>
> >>> The solution is to prevent from allocating pasid table if those
> >>> devices are subdevices of the
On 2/14/22 9:43 PM, Jason Gunthorpe wrote:
On Mon, Feb 14, 2022 at 02:39:18PM +0100, Greg Kroah-Hartman wrote:
A driver that sets this flag can still decide to enable the dma API on
its own. eg tegra drivers do this.
So you are just forcing the driver to manage this all on their own, so
how
On Mon, 2022-02-14 at 13:43 +0100, AngeloGioacchino Del Regno wrote:
> Il 14/02/22 13:40, Mark Brown ha scritto:
> > On Mon, Feb 14, 2022 at 02:08:16PM +0800, Yong Wu wrote:
> > > Use the common compare/release helpers from component.
> >
> > What's the story with dependencies here? I've just
On 2/14/22 8:52 PM, Joerg Roedel wrote:
On Mon, Feb 14, 2022 at 09:55:34AM +0800, Lu Baolu wrote:
The supported page sizes of an iommu_domain are saved in the pgsize_bitmap
field. Retrieve the value from the right place.
Signed-off-by: Lu Baolu
Reviewed-by: Robin Murphy
Link:
Hi Joerg,
On 2/14/22 10:14 PM, Joerg Roedel wrote:
On Mon, Feb 14, 2022 at 09:55:28AM +0800, Lu Baolu wrote:
v3:
- Remove ops check when dev_iommu_ops() is used.
- This version of series is available on github:
https://github.com/LuBaolu/intel-iommu/commits/iommu-domain-ops-v3
Lu
On 2/15/22 9:46 AM, Lu Baolu wrote:
On 2/14/22 8:49 PM, Joerg Roedel wrote:
On Mon, Feb 14, 2022 at 09:55:35AM +0800, Lu Baolu wrote:
+static inline const struct iommu_ops *dev_iommu_ops(struct device *dev)
+{
+ /*
+ * Assume that valid ops must be installed if iommu_probe_device()
+
On 2/14/22 8:49 PM, Joerg Roedel wrote:
On Mon, Feb 14, 2022 at 09:55:35AM +0800, Lu Baolu wrote:
+static inline const struct iommu_ops *dev_iommu_ops(struct device *dev)
+{
+ /*
+* Assume that valid ops must be installed if iommu_probe_device()
+* has succeeded. The
On 2/14/22 9:26 PM, Jason Gunthorpe wrote:
On Mon, Feb 14, 2022 at 09:55:37AM +0800, Lu Baolu wrote:
This converts all the feasible instances of dev->bus->iommu_ops to
dev_iommu_ops() in order to make the operation of obtaining iommu_ops
from a device consistent. The dev_iommu_ops() warns on
On 2/14/22 9:27 PM, Joerg Roedel wrote:
On Mon, Feb 07, 2022 at 04:12:40PM +0200, Andy Shevchenko wrote:
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 69230fd695ea..1036c1900b5c 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -813,6
On 2/14/22 5:32 PM, Huang Adrian wrote:
Hi Baolu,
On Mon, Feb 14, 2022 at 8:35 AM Lu Baolu wrote:
Hi Adrian,
The solution is to prevent from allocating pasid table if those
devices are subdevices of the VMD device.
Thanks for your patch!
Is this the only patch that is needed to make VMD
The patch titled
Subject: mm: enforce pageblock_order < MAX_ORDER
has been added to the -mm tree. Its filename is
mm-enforce-pageblock_order-max_order.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-enforce-pageblock_order-max_order.patch
and
The patch titled
Subject: cma: factor out minimum alignment requirement
has been added to the -mm tree. Its filename is
cma-factor-out-minimum-alignment-requirement.patch
This patch should soon appear at
On 14 Feb 2022, at 12:41, David Hildenbrand wrote:
> Some places in the kernel don't really expect pageblock_order >=
> MAX_ORDER, and it looks like this is only possible in corner cases:
>
> 1) CONFIG_DEFERRED_STRUCT_PAGE_INIT we'll end up freeing pageblock_order
>pages via
On 14 Feb 2022, at 12:41, David Hildenbrand wrote:
> Let's factor out determining the minimum alignment requirement for CMA
> and add a helpful comment.
>
> No functional change intended.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/powerpc/include/asm/fadump-internal.h | 5 -
>
Some places in the kernel don't really expect pageblock_order >=
MAX_ORDER, and it looks like this is only possible in corner cases:
1) CONFIG_DEFERRED_STRUCT_PAGE_INIT we'll end up freeing pageblock_order
pages via __free_pages_core(), which cannot possibly work.
2)
Let's factor out determining the minimum alignment requirement for CMA
and add a helpful comment.
No functional change intended.
Signed-off-by: David Hildenbrand
---
arch/powerpc/include/asm/fadump-internal.h | 5 -
arch/powerpc/kernel/fadump.c | 2 +-
Having pageblock_order >= MAX_ORDER seems to be able to happen in corner
cases and some parts of the kernel are not prepared for it.
For example, Aneesh has shown [1] that such kernels can be compiled on
ppc64 with 64k base pages by setting FORCE_MAX_ZONEORDER=8, which will run
into a
Add max opt argument to iova_domain_init_rcaches(), and use it to set the
rcaches range.
Also fix up all users to set this value (at 0, meaning use default),
including a wrapper for that, iova_domain_init_rcaches_default().
For dma-iommu.c we derive the iova_len argument from the IOMMU group
max
Add support to allow the maximum optimised DMA len be set for an IOMMU
group via sysfs.
This is much the same with the method to change the default domain type
for a group.
Signed-off-by: John Garry
---
.../ABI/testing/sysfs-kernel-iommu_groups | 16 +
drivers/iommu/iommu.c
Allow iommu_change_dev_def_domain() to create a new default domain, keeping
the same as current.
Also remove comment about the function purpose, which will become stale.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 49 ++-
include/linux/iommu.h
Some low-level drivers may request DMA mappings whose IOVA length exceeds
that of the current rcache upper limit.
This means that allocations for those IOVAs will never be cached, and
always must be allocated and freed from the RB tree per DMA mapping cycle.
This has a significant effect on
Function iommu_group_store_type() supports changing the default domain
of an IOMMU group.
Many conditions need to be satisfied and steps taken for this action to be
successful.
Satisfying these conditions and steps will be required for setting other
IOMMU group attributes, so factor into a
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This may be much more pronounced from commit 4e89dce72521 ("iommu/iova:
Retry from last rb tree node if iova search
On Mon, Feb 14, 2022 at 04:38:23PM +, Robin Murphy wrote:
> > This works better because the iommu code can hold the internal group
> > while it finds the bus/device and then invokes the driver op. We don't
> > have a lifetime problem anymore under that lock.
>
> That's certainly one of the
On Mon, Feb 07 2022 at 15:02, Fenghua Yu wrote:
> Since allocating, freeing and fixing up PASID are changed, the
> documentation is updated to reflect the changes.
>
> Originally-by: Ashok Raj
> Signed-off-by: Fenghua Yu
> Reviewed-by: Tony Luck
Acked-by: Thomas Gleixner
On Mon, Feb 07 2022 at 15:02, Fenghua Yu wrote:
> PASIDs are process wide. It was attempted to use refcounted PASIDs to
> free them when the last thread drops the refcount. This turned out to
> be complex and error prone. Given the fact that the PASID space is 20
> bits, which allows up to 1M
On Mon, Feb 07 2022 at 15:02, Fenghua Yu wrote:
> A new mm doesn't have a PASID yet when it's created. Initialize
> the mm's PASID on fork() or for init_mm to INVALID_IOASID (-1).
>
> INIT_PASID (0) is reserved for kernel legacy DMA PASID. It cannot be
> allocated to a user process. Initializing
On 2022-02-14 14:56, Jason Gunthorpe via iommu wrote:
On Mon, Feb 14, 2022 at 02:10:19PM +, Robin Murphy wrote:
On 2022-02-14 12:45, Jason Gunthorpe wrote:
On Mon, Feb 14, 2022 at 12:09:36PM +, Robin Murphy wrote:
On 2022-01-06 02:20, Lu Baolu wrote:
Expose an interface to replace
On 14 Feb 2022, at 2:59, Christophe Leroy wrote:
> Le 11/02/2022 à 17:41, Zi Yan a écrit :
>> From: Zi Yan
>>
>> alloc_contig_range() worked at MAX_ORDER-1 granularity to avoid merging
>> pageblocks with different migratetypes. It might unnecessarily convert
>> extra pageblocks at the beginning
On 14 Feb 2022, at 2:26, Christoph Hellwig wrote:
>> +int
>> +isolate_single_pageblock(unsigned long boundary_pfn, gfp_t gfp_flags, int
>> isolate_before_boundary);
>
> Please avoid the completely unreadably long line. i.e.
>
> int isolate_single_pageblock(unsigned long boundary_pfn, gfp_t
On Mon, Feb 14, 2022 at 03:18:31PM +, Robin Murphy wrote:
> Arguably, iommu_attach_device() could be renamed something like
> iommu_attach_group_for_dev(), since that's effectively the semantic that all
> the existing API users want anyway (even VFIO at the high level - the group
> is the
On 2022-02-14 14:39, Joerg Roedel wrote:
On Mon, Feb 14, 2022 at 09:03:13AM -0400, Jason Gunthorpe wrote:
Groups should disappear into an internal implementation detail, not be
so prominent in the API.
Not going to happen, IOMMU groups are ABI and todays device assignment
code, including
On Mon, Feb 14, 2022 at 03:23:07PM +0100, Joerg Roedel wrote:
> Device drivers calling into iommu_attach_device() is seldom a good
> idea. In this case the sound device has some generic hardware
> interface so that an existing sound driver can be re-used. Making this
> driver call iommu-specific
On Mon, Feb 14, 2022 at 02:10:19PM +, Robin Murphy wrote:
> On 2022-02-14 12:45, Jason Gunthorpe wrote:
> > On Mon, Feb 14, 2022 at 12:09:36PM +, Robin Murphy wrote:
> > > On 2022-01-06 02:20, Lu Baolu wrote:
> > > > Expose an interface to replace the domain of an iommu group for
> > > >
On Thu, Feb 03, 2022 at 05:59:20PM +0800, John Garry wrote:
> Currently the rcache structures are allocated for all IOVA domains, even if
> they do not use "fast" alloc+free interface. This is wasteful of memory.
>
> In addition, fails in init_iova_rcaches() are not handled safely, which is
>
On Mon, Feb 14, 2022 at 09:03:13AM -0400, Jason Gunthorpe wrote:
> Groups should disappear into an internal implementation detail, not be
> so prominent in the API.
Not going to happen, IOMMU groups are ABI and todays device assignment
code, including user-space, relies on them.
Groups implement
On 2022-02-03 09:59, John Garry wrote:
Currently the rcache structures are allocated for all IOVA domains, even if
they do not use "fast" alloc+free interface. This is wasteful of memory.
In addition, fails in init_iova_rcaches() are not handled safely, which is
less than ideal.
Make "fast"
On Mon, Feb 14, 2022 at 10:02:36AM -0400, Jason Gunthorpe wrote:
> That works for VFIO, but it doesn't work for other in-kernel
> drivers.. Is there something ensuring the group is only the GPU and
> sound device? Is the GPU never an addin card?
GPUs supporting this functionality are always
On Mon, Feb 14, 2022 at 09:55:28AM +0800, Lu Baolu wrote:
> v3:
> - Remove ops check when dev_iommu_ops() is used.
> - This version of series is available on github:
>https://github.com/LuBaolu/intel-iommu/commits/iommu-domain-ops-v3
>
> Lu Baolu (10):
> iommu/vt-d: Remove guest pasid
On 2022-02-14 12:45, Jason Gunthorpe wrote:
On Mon, Feb 14, 2022 at 12:09:36PM +, Robin Murphy wrote:
On 2022-01-06 02:20, Lu Baolu wrote:
Expose an interface to replace the domain of an iommu group for frameworks
like vfio which claims the ownership of the whole iommu group.
But if the
On Mon, Feb 14, 2022 at 02:40:56PM +0100, Joerg Roedel wrote:
> On Mon, Feb 14, 2022 at 09:15:44AM -0400, Jason Gunthorpe wrote:
> > But how does the sound device know that this has been done to it?
> >
> > eg how do we know the sound device hasn't been bound to VFIO or
> > something at this
On Mon, Feb 14, 2022 at 10:57:03AM +0800, Lu Baolu wrote:
> Replace the existing global device_domain_list with an array so that it
> could be rapidly searched. The index of the array is composed by the PCI
> segment, bus and devfn. Use RCU for lock protection.
>
> Signed-off-by: Lu Baolu
>
On Mon, Feb 14, 2022 at 07:28:40PM +0800, Tianyu Lan wrote:
> On 2/14/2022 4:19 PM, Christoph Hellwig wrote:
>> Adding a function to set the flag doesn't really change much. As Robin
>> pointed out last time you should fine a way to just call
>> swiotlb_init_with_tbl directly with the memory
On Mon, Feb 14, 2022 at 02:39:18PM +0100, Greg Kroah-Hartman wrote:
> > A driver that sets this flag can still decide to enable the dma API on
> > its own. eg tegra drivers do this.
>
> So you are just forcing the driver to manage this all on their own, so
> how about, "driver_managed_dma", or
On Mon, Feb 14, 2022 at 02:37:15PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 14, 2022 at 09:18:53AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 14, 2022 at 10:59:50AM +0100, Greg Kroah-Hartman wrote:
> >
> > > > + if (ret && !drv->no_kernel_api_dma)
> > > > +
On Mon, Feb 14, 2022 at 09:15:44AM -0400, Jason Gunthorpe wrote:
> But how does the sound device know that this has been done to it?
>
> eg how do we know the sound device hasn't been bound to VFIO or
> something at this point?
The iommu_attach_group() call will fail when the group (which
On Mon, Feb 14, 2022 at 09:11:17AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 01:51:06PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Feb 14, 2022 at 08:38:42AM -0400, Jason Gunthorpe wrote:
> > > On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> > > > On Tue, Jan
On Mon, Feb 14, 2022 at 09:18:53AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 10:59:50AM +0100, Greg Kroah-Hartman wrote:
>
> > > + if (ret && !drv->no_kernel_api_dma)
> > > + iommu_device_unuse_dma_api(dev);
> >
> > So you are now going to call this for every platform
On Mon, Feb 07, 2022 at 04:12:40PM +0200, Andy Shevchenko wrote:
> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index 69230fd695ea..1036c1900b5c 100644
> --- a/include/linux/intel-iommu.h
> +++ b/include/linux/intel-iommu.h
> @@ -813,6 +813,8 @@ bool
On 03/02/2022 11:34, Michael S. Tsirkin wrote:
On Thu, Feb 03, 2022 at 05:59:20PM +0800, John Garry wrote:
Currently the rcache structures are allocated for all IOVA domains, even if
they do not use "fast" alloc+free interface. This is wasteful of memory.
In addition, fails in
On Mon, Feb 14, 2022 at 09:55:37AM +0800, Lu Baolu wrote:
> This converts all the feasible instances of dev->bus->iommu_ops to
> dev_iommu_ops() in order to make the operation of obtaining iommu_ops
> from a device consistent. The dev_iommu_ops() warns on NULL ops, so
> we don't need to keep the
On Sun, Feb 06, 2022 at 09:29:45PM +0100, David Heidelberg wrote:
> Use the dev_err_probe() helper to simplify error handling during probe.
> This also handle scenario, when EDEFER is returned and useless error is
> printed.
>
> Fixes warnings as:
> msm_iommu 750.iommu: could not get
On Mon, Feb 14, 2022 at 10:59:50AM +0100, Greg Kroah-Hartman wrote:
> > + if (ret && !drv->no_kernel_api_dma)
> > + iommu_device_unuse_dma_api(dev);
>
> So you are now going to call this for every platform driver _unless_
> they set this flag?
Yes, it is necessary because VFIO
On Fri, Feb 04, 2022 at 10:34:05PM +0100, Heiko Stuebner wrote:
> Am Freitag, 4. Februar 2022, 21:16:41 CET schrieb Robin Murphy:
> > It's been a long time since there was any reason to register IOMMU
> > drivers early. Convert to the standard platform driver helper.
> >
> > CC: Heiko Stuebner
>
On Mon, Feb 14, 2022 at 12:27:05PM +0100, Joerg Roedel wrote:
> On Thu, Jan 06, 2022 at 10:33:45AM -0400, Jason Gunthorpe wrote:
> > But I'm not sure how this can work with multi-device groups - this
> > seems to assigns a domain setup for direct map, so perhaps this only
> > works if all devices
On Mon, Feb 14, 2022 at 01:51:06PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 14, 2022 at 08:38:42AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> > > > Multiple PCI
On Thu, Feb 10, 2022 at 12:29:05PM +, Robin Murphy wrote:
> Implementing ops->capable to always return false is pointless since it's
> the default behaviour anyway. Clean up the unnecessary implementations.
>
> Signed-off-by: Robin Murphy
> ---
>
> Spinning this out of my bus ops stuff
On Mon, Feb 14, 2022 at 12:39:36PM +0100, Joerg Roedel wrote:
> This extends iommu_attach_device() to behave as iommu_attach_group(),
> changing the domain for the whole group.
Of course, the only action to take is to change the domain of a
group..
> Wouldn't it be better to scrap the
On Tue, Feb 08, 2022 at 09:20:28AM +0900, Yoshihiro Shimoda wrote:
> This patch series is based on renesas-drivers-2022-01-11-v5.16 [1].
> Note that we have to prepare the following registers' setting
> in a bootloader (U-Boot) because the registers are protected.
> Otherwise, data mismatch
Hi Robin,
Is this quirk ok with the SMMU v3 driver? Just want to confirm that I'm on the
right way to dealing with the issue of our device.
Thanks.
On 2022/1/24 21:11, Yicong Yang wrote:
> The DMA of HiSilicon PTT device can only work with identical
> mapping. So add a quirk for the device to
On Mon, Feb 14, 2022 at 09:55:34AM +0800, Lu Baolu wrote:
> The supported page sizes of an iommu_domain are saved in the pgsize_bitmap
> field. Retrieve the value from the right place.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Robin Murphy
> Link:
>
On 2022/2/8 19:07, Yicong Yang wrote:
> On 2022/2/7 19:42, Jonathan Cameron wrote:
>> On Mon, 24 Jan 2022 21:11:11 +0800
>> Yicong Yang wrote:
>>
>>> HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex
>>> integrated Endpoint(RCiEP) device, providing the capability
>>> to dynamically
On Mon, Feb 14, 2022 at 08:38:42AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> > > Multiple PCI devices may be placed in the same IOMMU group because
> > > they cannot be
On Mon, Feb 14, 2022 at 09:55:35AM +0800, Lu Baolu wrote:
> +static inline const struct iommu_ops *dev_iommu_ops(struct device *dev)
> +{
> + /*
> + * Assume that valid ops must be installed if iommu_probe_device()
> + * has succeeded. The device ops are essentially for internal use
On Mon, Feb 14, 2022 at 12:09:36PM +, Robin Murphy wrote:
> On 2022-01-06 02:20, Lu Baolu wrote:
> > Expose an interface to replace the domain of an iommu group for frameworks
> > like vfio which claims the ownership of the whole iommu group.
>
> But if the underlying point is the new
Il 14/02/22 13:40, Mark Brown ha scritto:
On Mon, Feb 14, 2022 at 02:08:16PM +0800, Yong Wu wrote:
Use the common compare/release helpers from component.
What's the story with dependencies here? I've just got this one patch
with no cover letter...
Hello Mark,
I agree, the cover letter
On Mon, Feb 14, 2022 at 12:32:21PM +, Robin Murphy wrote:
> In this particular case it cannot fail on any system the driver actually
> runs on - it's a platform device so the dma_mask pointer is always
> initialised, then dma_direct_supported() on arm64 will always return true
> for any mask
On Mon, Feb 14, 2022 at 02:08:16PM +0800, Yong Wu wrote:
> Use the common compare/release helpers from component.
What's the story with dependencies here? I've just got this one patch
with no cover letter...
signature.asc
Description: PGP signature
On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> > Multiple PCI devices may be placed in the same IOMMU group because
> > they cannot be isolated from each other. These devices must either be
> > entirely under kernel
On 2022-02-14 11:43, Joerg Roedel wrote:
Adding more potential reviewers.
On Thu, Jan 06, 2022 at 10:43:02AM +0800, Jiasheng Jiang wrote:
Because of the possible failure of the dma_supported(), the
dma_set_mask_and_coherent() may return error num.
Therefore, it should be better to check it and
On 2022-01-06 02:20, Lu Baolu wrote:
Expose an interface to replace the domain of an iommu group for frameworks
like vfio which claims the ownership of the whole iommu group.
But if the underlying point is the new expectation that
iommu_{attach,detach}_device() operate on the device's whole
On Tue, Feb 01, 2022 at 07:11:40PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Replace acpi_bus_get_device() that is going to be dropped with
> acpi_fetch_acpi_dev().
>
> No intentional functional impact.
>
> Signed-off-by: Rafael J. Wysocki
> ---
>
Adding more potential reviewers.
On Thu, Jan 06, 2022 at 10:43:02AM +0800, Jiasheng Jiang wrote:
Because of the possible failure of the dma_supported(), the
dma_set_mask_and_coherent() may return error num.
Therefore, it should be better to check it and return the error if
fails.
Indeed, most
On Thu, Feb 10, 2022 at 09:47:45AM -0600, Suravee Suthikulpanit wrote:
> The current logic updates the I/O page table mode for the domain
> before calling the logic to free memory used for the page table.
> This results in IOMMU page table memory leak, and can be observed
> when launching VM w/
Adding more potential reviewers.
On Thu, Jan 06, 2022 at 10:43:02AM +0800, Jiasheng Jiang wrote:
> Because of the possible failure of the dma_supported(), the
> dma_set_mask_and_coherent() may return error num.
> Therefore, it should be better to check it and return the error if
> fails.
>
>
On Thu, Jan 06, 2022 at 10:20:48AM +0800, Lu Baolu wrote:
> int iommu_attach_device(struct iommu_domain *domain, struct device *dev)
> {
> struct iommu_group *group;
> - int ret;
> + int ret = 0;
> +
> + if (domain->type != IOMMU_DOMAIN_UNMANAGED)
> + return
On 2/14/2022 4:19 PM, Christoph Hellwig wrote:
Adding a function to set the flag doesn't really change much. As Robin
pointed out last time you should fine a way to just call
swiotlb_init_with_tbl directly with the memory allocated the way you
like it. Or given that we have quite a few of
On Thu, Jan 06, 2022 at 10:33:45AM -0400, Jason Gunthorpe wrote:
> But I'm not sure how this can work with multi-device groups - this
> seems to assigns a domain setup for direct map, so perhaps this only
> works if all devices are setup for direct map?
Right, at boot all devices in this group
On Fri, Feb 11, 2022 at 11:41:30AM -0500, Zi Yan wrote:
> From: Zi Yan
>
> has_unmovable_pages() is only used in mm/page_isolation.c. Move it from
> mm/page_alloc.c and make it static.
>
> Signed-off-by: Zi Yan
> Reviewed-by: Oscar Salvador
Reviewed-by: Mike Rapoport
> ---
>
Hi Jacob,
On Wed, Feb 09, 2022 at 01:52:49PM -0800, Jacob Pan wrote:
> Another option Ashok and I discussed is that we can make DMAR cache persist
> (which should be for explicitly listed devices in each DRHD) across PCI
> remove-rescan cycle, then we don't need the DMAR PCI bus notifier at all.
On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> Multiple PCI devices may be placed in the same IOMMU group because
> they cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture. This
> checks and sets DMA
On Tue, Jan 04, 2022 at 09:56:32AM +0800, Lu Baolu wrote:
> The bus_type structure defines dma_configure() callback for bus drivers
> to configure DMA on the devices. This adds the paired dma_cleanup()
> callback and calls it during driver unbinding so that bus drivers can do
> some cleanup work.
On Tue, Jan 04, 2022 at 09:56:34AM +0800, Lu Baolu wrote:
> Multiple platform devices may be placed in the same IOMMU group because
> they cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture. This
> checks and sets
On Tue, Jan 04, 2022 at 02:08:36AM -0800, Christoph Hellwig wrote:
> All these bus callouts still looks horrible and just create tons of
> boilerplate code.
I can't remember anymore what one vs. the other looks like. Having an
explicit "opt-in" for a bus is good, in that no code breaks and only
Hi,
Le lun., févr. 14 2022 at 14:08:02 +0800, Yong Wu
a écrit :
Use the common compare helper from component.
Cc: Paul Cercueil
Cc: linux-m...@vger.kernel.org
Signed-off-by: Yong Wu
Acked-by: Paul Cercueil
Cheers,
-Paul
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 7 +--
1
Hi Baolu,
On Mon, Feb 14, 2022 at 8:35 AM Lu Baolu wrote:
>
> Hi Adrian,
>
> > The solution is to prevent from allocating pasid table if those
> > devices are subdevices of the VMD device.
>
> Thanks for your patch!
>
> Is this the only patch that is needed to make VMD devices work in VT-d
>
Adding a function to set the flag doesn't really change much. As Robin
pointed out last time you should fine a way to just call
swiotlb_init_with_tbl directly with the memory allocated the way you
like it. Or given that we have quite a few of these trusted hypervisor
schemes maybe add an
Am Montag, 14. Februar 2022, 07:08:09 CET schrieb Yong Wu:
> Use the common compare helper from component.
>
> Cc: Sandy Huang
> Cc: "Heiko St¨¹bner"
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Yong Wu
Acked-by: Heiko Stuebner
> ---
>
91 matches
Mail list logo
