From: Michael Schmitz
> Sent: 29 June 2022 00:09
>
> Hi Arnd,
>
> On 29/06/22 09:50, Arnd Bergmann wrote:
> > On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz
> > wrote:
> >> On 28/06/22 19:03, Geert Uytterhoeven wrote:
> The driver allocates bounce buffers using kmalloc if it hits an
> >>
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> It is not used anywhere. Remove it to avoid dead code.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfounda
On 2022-06-29 20:47, Nicolin Chen wrote:
On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote:
On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrote:
It's not used in VFIO context. "return 0" just satisfy the iommu
framework to go ahead. and yes, here we only allow the shared
"map
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> @@ -1062,11 +1040,14 @@ static int alloc_iommu(struct dmar_drhd_unit
> *drhd)
> if (!iommu)
> return -ENOMEM;
>
> - if (dmar_alloc_seq_id(iommu) < 0) {
> + iommu->seq_id = ida_alloc_range(&dmar_seq_ids, 0,
>
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> +struct iommu_domain_info {
> + struct intel_iommu *iommu;
> + unsigned int refcnt;
> + u16 did;
> +};
> +
> struct dmar_domain {
> int nid;/* node id */
> -
> - unsigned int iommu_refcnt[D
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> In the IOMMU hot-add path, there's a need to check whether an IOMMU
> has been probed. Instead of checking the IOMMU pointer in the global
> list, it's better to allocate a flag bit in iommu->flags for this
> purpose.
Sorry I didn't ge
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> The g_iommus is not used anywhere. Remove it to avoid dead code.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.l
> From: Lu Baolu
> Sent: Saturday, June 25, 2022 8:52 PM
>
> If the available hardware exceeds DMAR_UNITS_SUPPORTED (previously set
> to MAX_IO_APICS, or 128), it causes these messages: "DMAR: Failed to
> allocate seq_id", "DMAR: Parse DMAR table failure.", and "x2apic: IRQ
> remapping doesn't su
On 2022-06-30 08:33, Feng Tang wrote:
kmalloc will round up the request size to power of 2, and current
iova_magazine's size is 1032 (1024+8) bytes, so each instance
allocated will get 2048 bytes from kmalloc, causing around 1KB
waste.
And in some exstreme case, the memory wasted can trigger OOM
On Wed, 2022-06-29 at 12:47 -0700, Nicolin Chen wrote:
> On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrote:
> >
> > > > > It's not used in VFIO context. "return 0" just satisfy the
> > > > > iommu
> > > > > framework to go
This patchset adds MediaTek TTBR up to 35bit support for single normal zone.
Changes in v12:
- Update [PATCH 1/2]: remove GENMASK(31, 7)
- Update [PATCH 2/2]: remove MMU_PT_ADDR_MASK definition.
Changes in v11:
https://lore.kernel.org/linux-mediatek/20220630062508.23512-1-yf.w...@mediatek.com/
-
From: Yunfei Wang
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and
cause pgtable PA size larger than 32bit.
Since Mediatek IOMMU hardware support at most 35bit PA in pgtable,
so add a quirk to allow the PA of pgtables support up to bit35.
Signed-off-by: Ning Li
Signed-off-by:
From: Yunfei Wang
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA. So add
the quirk IO_PGTABLE_QUIRK_ARM_MTK_TTBR_EXT to let level 1 and level 2
pgtable support at most 35bit PA.
Signed-off-by: Ning Li
Signed-off-by: Yunfei Wang
---
drivers/iommu/mtk_iommu.c | 13 +++--
On 30/06/2022 10:02, Robin Murphy wrote:
On 2022-06-30 08:33, Feng Tang wrote:
kmalloc will round up the request size to power of 2, and current
iova_magazine's size is 1032 (1024+8) bytes, so each instance
allocated will get 2048 bytes from kmalloc, causing around 1KB
waste.
And in some exstre
Le 30/06/2022 à 10:04, David Laight a écrit :
> From: Michael Schmitz
>> Sent: 29 June 2022 00:09
>>
>> Hi Arnd,
>>
>> On 29/06/22 09:50, Arnd Bergmann wrote:
>>> On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz
>>> wrote:
On 28/06/22 19:03, Geert Uytterhoeven wrote:
>> The driver allo
Currently acpi_viot_init() gets called after the pci
device has been scanned and pci_enable_acs() has been called.
So pci_request_acs() fails to be taken into account leading
to wrong single iommu group topologies when dealing with
multi-function root ports for instance.
We cannot simply move the
> From: Robin Murphy
> Sent: Thursday, June 30, 2022 4:22 PM
>
> On 2022-06-29 20:47, Nicolin Chen wrote:
> > On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote:
> >> On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrote:
> >>
> > It's not used in VFIO context. "return 0" just
On Thu, Jun 30, 2022 at 11:40:59AM +0200, Eric Auger wrote:
> Currently acpi_viot_init() gets called after the pci
> device has been scanned and pci_enable_acs() has been called.
> So pci_request_acs() fails to be taken into account leading
> to wrong single iommu group topologies when dealing with
On 2022-06-30 10:37, John Garry wrote:
On 30/06/2022 10:02, Robin Murphy wrote:
On 2022-06-30 08:33, Feng Tang wrote:
kmalloc will round up the request size to power of 2, and current
iova_magazine's size is 1032 (1024+8) bytes, so each instance
allocated will get 2048 bytes from kmalloc, causi
From: Christophe Leroy
> Sent: 30 June 2022 10:40
>
> Le 30/06/2022 à 10:04, David Laight a écrit :
> > From: Michael Schmitz
> >> Sent: 29 June 2022 00:09
> >>
> >> Hi Arnd,
> >>
> >> On 29/06/22 09:50, Arnd Bergmann wrote:
> >>> On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz
> >>> wrote:
> >
[ 4.319253] iommu: Adding device :06:00.2 to group 5
[ 4.325869] iommu: Adding device :20:01.0 to group 15
[ 4.332648] iommu: Adding device :20:02.0 to group 16
[ 4.338946] swapper/0 invoked oom-killer:
gfp_mask=0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null
As reported in [0], DMA mappings whose size exceeds the IOMMU IOVA caching
limit may see a big performance hit.
This series introduces a new DMA mapping API, dma_opt_mapping_size(), so
that drivers may know this limit when performance is a factor in the
mapping.
The SCSI SAS transport code is mod
Streaming DMA mapping involving an IOMMU may be much slower for larger
total mapping size. This is because every IOMMU DMA mapping requires an
IOVA to be allocated and freed. IOVA sizes above a certain limit are not
cached, which can have a big impact on DMA mapping performance.
Provide an API for
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 limit, as IOVAs allocated
above this limit must always be newly allocated, which may
The shost->max_sectors is repeatedly capped according to the host DMA
mapping limit for each sdev in __scsi_init_queue(). This is unnecessary, so
set only once when adding the host.
Signed-off-by: John Garry
---
drivers/scsi/hosts.c| 5 +
drivers/scsi/scsi_lib.c | 4
2 files changed
Streaming DMA mappings may be considerably slower when mappings go through
an IOMMU and the total mapping length is somewhat long. This is because the
IOMMU IOVA code allocates and free an IOVA for each mapping, which may
affect performance.
For performance reasons set the request queue max_sector
ATA devices (struct ata_device) have a max_sectors field which is
configured internally in libata. This is then used to (re)configure the
associated sdev request queue max_sectors value from how it is earlier set
in __scsi_init_queue(). In __scsi_init_queue() the max_sectors value is set
according
Hi Robin,
On Thu, Jun 30, 2022 at 10:02:00AM +0100, Robin Murphy wrote:
> On 2022-06-30 08:33, Feng Tang wrote:
> > kmalloc will round up the request size to power of 2, and current
> > iova_magazine's size is 1032 (1024+8) bytes, so each instance
> > allocated will get 2048 bytes from kmalloc, ca
The expression 1 << 31 results in undefined behaviour because the type of
integer constant 1 is (signed) int and the result of shifting 1 by 31 bits
is not representable in the (signed) int type.
Change the type of 1 to unsigned int by adding the U suffix.
Signed-off-by: Xenia Ragiadakou
---
dr
kmalloc will round up the request size to power of 2, and current
iova_magazine's size is 1032 (1024+8) bytes, so each instance
allocated will get 2048 bytes from kmalloc, causing around 1KB
waste.
And in some exstreme case, the memory wasted can trigger OOM as
reported in 2019 on a crash kernel w
If CONFIG_DMA_DECLARE_COHERENT is not set,
make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- will be failed, like this:
drivers/remoteproc/remoteproc_core.c: In function ‘rproc_rvdev_release’:
./include/linux/dma-map-ops.h:182:42: error: statement with no effect
[-Werror=unused-value]
#define dma
Thanks, this looks good with a minor nit below:
Reviewed-by: Christoph Hellwig
Mathieu, can you pick this up through your tree as that is where the
offending commit was merged through?
> Fixes: e61c451476e6("dma-mapping: Add dma_release_coherent_memory to DMA API")
missing space before the ope
On 2022-06-29 23:41, Logan Gunthorpe wrote:
On 2022-06-29 13:15, Robin Murphy wrote:
On 2022-06-29 16:57, Logan Gunthorpe wrote:
On 2022-06-29 06:07, Robin Murphy wrote:
On 2022-06-15 17:12, Logan Gunthorpe wrote:
When a PCI P2PDMA page is seen, set the IOVA length of the segment
to zero
On 2022-06-30 10:29, yf.w...@mediatek.com wrote:
From: Yunfei Wang
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and
cause pgtable PA size larger than 32bit.
Since Mediatek IOMMU hardware support at most 35bit PA in pgtable,
so add a quirk to allow the PA of pgtables support u
On 2022-06-30 10:29, yf.w...@mediatek.com wrote:
From: Yunfei Wang
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA. So add
the quirk IO_PGTABLE_QUIRK_ARM_MTK_TTBR_EXT to let level 1 and level 2
pgtable support at most 35bit PA.
FWIW,
Reviewed-by: Robin Murphy
Signed-off-by:
On Thu, Jun 30, 2022 at 05:33:16PM +0800, Yong Wu wrote:
> External email: Use caution opening links or attachments
>
>
> On Wed, 2022-06-29 at 12:47 -0700, Nicolin Chen wrote:
> > On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote:
> > > On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yon
On Thu, Jun 30, 2022 at 09:21:42AM +0100, Robin Murphy wrote:
> External email: Use caution opening links or attachments
>
>
> On 2022-06-29 20:47, Nicolin Chen wrote:
> > On Fri, Jun 24, 2022 at 03:19:43PM -0300, Jason Gunthorpe wrote:
> > > On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrot
From: Tianyu Lan
Traditionally swiotlb was not performance critical because it was only
used for slow devices. But in some setups, like TDX/SEV confidential
guests, all IO has to go through swiotlb. Currently swiotlb only has a
single lock. Under high IO load with multiple CPUs this can lead to
s
On 6/29/2022 10:04 PM, Christoph Hellwig wrote:
On Mon, Jun 27, 2022 at 11:31:50AM -0400, Tianyu Lan wrote:
From: Tianyu Lan
When initialize swiotlb bounce buffer, smp_init() has not been
called and cpu number can not be got from num_online_cpus().
Use the number of lapic entry to set swiotlb
Hi Christoph,
On 29/06/22 18:21, Christoph Hellwig wrote:
On Wed, Jun 29, 2022 at 11:09:00AM +1200, Michael Schmitz wrote:
And all SCSI buffers are allocated using kmalloc? No way at all for user
space to pass unaligned data?
Most that you will see actually comes from the page allocator. But
Hi Christoph,
On 29/06/22 18:25, Christoph Hellwig wrote:
On Wed, Jun 29, 2022 at 09:38:00AM +1200, Michael Schmitz wrote:
That's one of the 'liberties' I alluded to. The reason I left these in is
that I'm none too certain what device feature the DMA API uses to decide a
device isn't cache-cohe
On Fri, 24 Jun 2022 18:51:44 +0100
Robin Murphy wrote:
> Since IOMMU groups are mandatory for drivers to support, it stands to
> reason that any device which has been successfully added to a group
> must be on a bus supported by that IOMMU driver, and therefore a domain
> viable for any device in
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 V
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 b
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 those
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:
https://lore.kernel.o
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 iommu_at
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
Revie
On 2022-06-30 08:56, Robin Murphy wrote:
> On 2022-06-29 23:41, Logan Gunthorpe wrote:
>>
>>
>> On 2022-06-29 13:15, Robin Murphy wrote:
>>> On 2022-06-29 16:57, Logan Gunthorpe wrote:
On 2022-06-29 06:07, Robin Murphy wrote:
> On 2022-06-15 17:12, Logan Gunthorpe wrote:
>
On 2022-06-29 10:06, Logan Gunthorpe wrote:
>
>
>
> On 2022-06-29 00:46, Christoph Hellwig wrote:
>> On Wed, Jun 15, 2022 at 10:12:28AM -0600, Logan Gunthorpe wrote:
>>> Consecutive zone device pages should not be merged into the same sgl
>>> or bvec segment with other types of pages or if t
On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote:
>
> * Saravana Kannan [220623 08:17]:
> > 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:
> > > > > This issue is no directly re
On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan wrote:
>
> On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote:
> >
> > * Saravana Kannan [220623 08:17]:
> > > On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren wrote:
> > > >
> > > > * Saravana Kannan [220622 19:05]:
> > > > > On Tue, Jun 21, 2022
On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote:
>
> On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan wrote:
> >
> > On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote:
> > >
> > > * Saravana Kannan [220623 08:17]:
> > > > On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren wrote:
> > > > >
> > >
On 6/30/22 21:08, John Garry wrote:
> The shost->max_sectors is repeatedly capped according to the host DMA
> mapping limit for each sdev in __scsi_init_queue(). This is unnecessary, so
> set only once when adding the host.
>
> Signed-off-by: John Garry
> ---
> drivers/scsi/hosts.c| 5 +
On 6/30/22 21:08, John Garry wrote:
> Streaming DMA mappings may be considerably slower when mappings go through
> an IOMMU and the total mapping length is somewhat long. This is because the
> IOMMU IOVA code allocates and free an IOVA for each mapping, which may
> affect performance.
>
> For perf
On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein
wrote:
>
> 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
On 6/30/22 4:21 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Saturday, June 25, 2022 8:52 PM
@@ -1062,11 +1040,14 @@ static int alloc_iommu(struct dmar_drhd_unit
*drhd)
if (!iommu)
return -ENOMEM;
- if (dmar_alloc_seq_id(iommu) < 0) {
+ iommu->seq_id = ida_al
These patches are on top of driver-core-next.
Even if stdout-path isn't set in DT, this patch should take console
probe times back to how they were before the deferred_probe_timeout
clean up series[1].
v1->v2:
- Fixed the accidental change that Tobias pointed out.
- Added Tested-by tag
[1] -
ht
This flag only needs to be set for drivers of devices that meet all the
following conditions:
- Need to probe successfully before userspace init in started
- Have optional suppliers
- Can't wait for deferred_probe_timeout to expire
fw_devlink=on uses this info, as needed, to ignore dependencies on
With commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by
default") the probing of TTY consoles could get delayed if they have
optional suppliers that are listed in DT, but those suppliers don't
probe by the time kernel boot finishes. The console devices will probe
eventually after driver_
On 6/30/22 4:28 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Saturday, June 25, 2022 8:52 PM
+struct iommu_domain_info {
+ struct intel_iommu *iommu;
+ unsigned int refcnt;
+ u16 did;
+};
+
struct dmar_domain {
int nid;/* node id */
-
- u
On 6/30/22 4:29 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Saturday, June 25, 2022 8:52 PM
In the IOMMU hot-add path, there's a need to check whether an IOMMU
has been probed. Instead of checking the IOMMU pointer in the global
list, it's better to allocate a flag bit in iommu->flags for this
Hi John,
On Thu, Jun 30, 2022 at 11:52:18AM +0100, John Garry wrote:
> > > >
> > > > > [ 4.319253] iommu: Adding device :06:00.2 to group 5
> > > > > [ 4.325869] iommu: Adding device :20:01.0 to group 15
> > > > > [ 4.332648] iommu: Adding device :20:02.0 to group 16
On 4/8/22 01:23, Jason Gunthorpe via iommu wrote:
IOMMU_CACHE means that normal DMAs do not require any additional coherency
mechanism and is the basic uAPI that VFIO exposes to userspace. For
instance VFIO applications like DPDK will not work if additional coherency
operations are required.
* Saravana Kannan [220630 23:25]:
> On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote:
> >
> > On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan
> > wrote:
> > >
> > > On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote:
> > > >
> > > > * Saravana Kannan [220623 08:17]:
> > > > > On Thu, Jun 23
This patchset contains misc improve patches. Mainly to improve safety from
invalid dts input.
Change notes:
v3: a) Add platform_device_put from Robin.
b) Use component_match_add instead component_match_add_release suggested
from Robin.
v2:
https://lore.kernel.org/linux-mediatek/2022061
Mute the probe defer log:
[2.654806] mtk-iommu 14018000.iommu: mm dts parse fail(-517).
[2.656168] mtk-iommu 1c01f000.iommu: mm dts parse fail(-517).
Fixes: d2e9a1102cfc ("iommu/mediatek: Contain MM IOMMU flow with the MM TYPE")
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Re
Add platform_device_put to match with of_find_device_by_node.
Meanwhile, I add a new variable "pcommdev" which is for smi common device.
Otherwise, "platform_device_put(plarbdev)" for smi-common dev may be not
readable. And add a checking for whether pcommdev is NULL.
Fixes: d2e9a1102cfc ("iommu/
In order to simplify the error patch(avoid call of_node_put), Use
component_match_add instead component_match_add_release since we are only
interested in the "device" here. Then we could always call of_node_put in
normal path.
Strictly this is not a fixes patch, but it is a prepare for adding the
The mtk_iommu_mm_dts_parse will parse the smi larbs nodes. if the i+1
larb is parsed fail, we should put_device for the 0..i larbs.
There are two places need to comment:
1) The larbid may be not linear mapping, we should loop whole
the array in the error path.
2) I move this line position: "dat
From: Guenter Roeck
Fix the smatch warnings:
drivers/iommu/mtk_iommu.c:878 mtk_iommu_mm_dts_parse() error: uninitialized
symbol 'larbnode'.
If someone abuse the dtsi node(Don't follow the definition of dt-binding),
for example "mediatek,larbs" is provided as boolean property, "larb_nr"
will be z
No functional change. Just improve safety from dts.
All the larbs that connect to one IOMMU must connect with the same
smi-common. This patch checks all the mediatek,smi property for each
larb, If their mediatek,smi are different, it will return fails.
Also avoid there is no available smi-larb nod
Just remove a unused variable that only is for mtk_iommu_v1.
Signed-off-by: Yong Wu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Matthias Brugger
---
drivers/iommu/mtk_iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
i
Hi Saravana,
Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan:
> On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein
>
> wrote:
> > Hi,
> >
> > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren:
> > > Hi,
> > >
> > > * Saravana Kannan [700101 02:00]:
> > > > Now that
> From: Alexey Kardashevskiy
> Sent: Friday, July 1, 2022 12:58 PM
>
> On 4/8/22 01:23, Jason Gunthorpe via iommu wrote:
> > IOMMU_CACHE means that normal DMAs do not require any additional
> coherency
> > mechanism and is the basic uAPI that VFIO exposes to userspace. For
> > instance VFIO appli
> From: Baolu Lu
> Sent: Friday, July 1, 2022 11:13 AM
>
> On 6/30/22 4:29 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Saturday, June 25, 2022 8:52 PM
> >>
> >> In the IOMMU hot-add path, there's a need to check whether an IOMMU
> >> has been probed. Instead of checking the IOMMU point
* Tony Lindgren [220701 08:33]:
> * Saravana Kannan [220630 23:25]:
> > On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote:
> > >
> > > On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan
> > > wrote:
> > > >
> > > > On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote:
> > > > >
> > > > > * Sarava
On 7/1/22 16:07, Tian, Kevin wrote:
From: Alexey Kardashevskiy
Sent: Friday, July 1, 2022 12:58 PM
On 4/8/22 01:23, Jason Gunthorpe via iommu wrote:
IOMMU_CACHE means that normal DMAs do not require any additional
coherency
mechanism and is the basic uAPI that VFIO exposes to userspace. Fo
On 2022/7/1 04:36, Nicolin Chen wrote:
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
79 matches
Mail list logo
