On 7/28/21 11:58 PM, Robin Murphy wrote:
When passthrough is enabled, the default strictness policy becomes
irrelevant, since any subsequent runtime override to a DMA domain type
now embodies an explicit choice of strictness as well. Save on noise by
only logging the default policy when it is mea
On 7/28/21 11:58 PM, Robin Murphy wrote:
Allocating and enabling a flush queue is in fact something we can
reasonably do while a DMA domain is active, without having to rebuild it
from scratch. Thus we can allow a strict -> non-strict transition from
sysfs without requiring to unbind the device's
On 7/28/21 11:58 PM, Robin Murphy wrote:
Factor out flush queue setup from the initial domain init so that we
can potentially trigger it from sysfs later on in a domain's lifetime.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 30 --
include/linux/dm
On 7/28/21 11:58 PM, Robin Murphy wrote:
To parallel the sysfs behaviour, merge the new build-time option
for DMA domain strictness into the default domain type choice.
Suggested-by: Joerg Roedel
Signed-off-by: Robin Murphy
---
drivers/iommu/Kconfig | 80 +
On 7/28/21 11:58 PM, Robin Murphy wrote:
The sysfs interface for default domain types exists primarily so users
can choose the performance/security tradeoff relevant to their own
workload. As such, the choice between the policies for DMA domains fits
perfectly as an additional point on that scale
On 7/29/21 5:36 PM, Robin Murphy wrote:
On 2021-07-29 08:13, Lu Baolu wrote:
Hi Robin,
On 7/28/21 11:58 PM, Robin Murphy wrote:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 982545234cf3..eecb5657de69 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -136,6 +
On 7/28/21 11:58 PM, Robin Murphy wrote:
In preparation for the strict vs. non-strict decision for DMA domains
to be expressed in the domain type, make sure we expose our flush queue
awareness by accepting the new domain type, and test the specific
feature flag where we want to identify DMA domai
On 7/28/21 11:58 PM, Robin Murphy wrote:
Promote the difference between strict and non-strict DMA domains from an
internal detail to a distinct domain feature and type, to pave the road
for exposing it through the sysfs default domain interface.
Signed-off-by: Robin Murphy
---
drivers/iommu/d
On 7/28/21 11:58 PM, Robin Murphy wrote:
iommu_dma_init_domain() is now only called from iommu_setup_dma_ops(),
which has already assumed dev to be non-NULL.
Reviewed-by: John Garry
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 5 +
1 file changed, 1 insertion(+), 4 deleti
On 7/28/21 11:58 PM, Robin Murphy wrote:
IOVA cookies are now got and put by core code, so we no longer need to
export these to modular drivers. The export for getting MSI cookies
stays, since VFIO can still be a module, but it was already relying on
someone else putting them, so that aspect is u
On 7/28/21 11:58 PM, Robin Murphy wrote:
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/intel/iommu.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index c12cc955389a..7e168634c433
On 7/28/21 11:58 PM, Robin Murphy wrote:
Now that everyone has converged on iommu-dma for IOMMU_DOMAIN_DMA
support, we can abandon the notion of drivers being responsible for the
cookie type, and consolidate all the management into the core code.
CC: Marek Szyprowski
CC: Yoshihiro Shimoda
CC:
> On 29-Jul-2021, at 9:43 PM, Will Deacon wrote:
>
> On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
>> On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
>>> next-20210723 was good. The boot failure seems to have been introduced with
>>> next-20210726.
>>>
>>> I
Hi Konrad:
Thanks for your review.
On 7/30/2021 12:29 AM, Konrad Rzeszutek Wilk wrote:
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1fa81c096c1d..6866e5784b53 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -194,8 +194,13 @@ static void swiotlb_init_io_tlb_
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Dafna Hirschfeld
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/dts/mediatek/m
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5 -
2 files changed, 7 deletions(-)
diff --gi
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
Acked-b
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Chun-
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_get for smi via
ovl or rdma device.
CC:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Reviewed-
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_init is
also unnecessary. Remove it too.
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enab
Prepare for adding device_link.
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is
ready, then all the iommu consumer always is after the smi driver.
When
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need the property.
And IOMMU also know which larb this consumer connec
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_init) from []
(of_iommu_xlate+0x7c/0x12c)
[] (of_iommu_xlate) from []
(of_iommu_c
MediaTek IOMMU block diagram always like below:
M4U
|
smi-common
|
-
| | ...
| |
larb1 larb2
| |
vdec venc
All the consumer connect with smi-larb, then connect with smi-common.
When the consumer works, it should
On 7/30/2021 12:05 AM, Dave Hansen wrote:
On 7/29/21 8:02 AM, Tianyu Lan wrote:
There is x86_hyper_type to identify hypervisor type and we may check
this variable after checking X86_FEATURE_HYPERVISOR.
static inline bool hv_is_isolation_supported(void)
{
if (!cpu_feature_enabled(X86_FEA
On Wed, Jul 28, 2021 at 04:51:27PM -0500, Suthikulpanit, Suravee wrote:
> Lennert,
Hi Suravee,
> > This patch makes iommu/amd call report_iommu_fault() when an I/O page
> > fault occurs, which has two effects:
> >
> > 1) It allows device drivers to register a callback to be notified of
> >
Hi Andy,
On 7/30/21 12:35 AM, Andy Shevchenko wrote:
Compiler is not happy about hidden declaration of intel_iommu_ops.
.../drivers/iommu/intel/iommu.c:414:24: warning: symbol 'intel_iommu_ops' was
not declared. Should it be static?
Move declaration to header file to make compiler happy.
Th
在 2021/7/29 18:59, Robin Murphy 写道:
On 2021-07-29 03:55, chenxiang (M) wrote:
Hi Robin,
在 2021/7/28 23:58, Robin Murphy 写道:
Hi all,
Here's v2 where things start to look more realistic, hence the expanded
CC list. The patches are now based on the current iommu/core branch to
take John's iom
Hi,
On Thu, Jul 29, 2021 at 3:33 PM Doug Anderson wrote:
>
> I was definitely getting some inconsistencies in my tests where the
> eMMC speeds were getting into a bad state, but I don't believe it's
> related to your patch series.
I think this was just me being an idiot. I forgot that I'd been
r
Hi,
On Wed, Jul 28, 2021 at 8:59 AM Robin Murphy wrote:
>
> Hi all,
>
> Here's v2 where things start to look more realistic, hence the expanded
> CC list. The patches are now based on the current iommu/core branch to
> take John's iommu_set_dma_strict() cleanup into account.
>
> The series remiai
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
pci_map_single_1() can fail for different reasons, but since the only
supported type of error return is DMA_MAPPING_ERROR, we coalesce those
errors into EIO.
ENOMEM is returned when no page tables can b
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
In the case of a DMA_MAPPING_ERROR, -EIO is returned. Otherwise,
-ENOMEM or -EINVAL is returned depending on the error from
__map_sg_chunk().
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorp
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of the
->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Russell King
Cc: Thomas Bogendoerfer
---
arch
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
Propagate the error up if vio_dma_iommu_map_sg() fails.
ppc_iommu_map_sg() may fail either because of iommu_range_alloc() or
because of tbl->it_ops->set(). The former only supports returning an
error wi
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
In the case of a dma_mapping_error() return -EIO as the actual cause
is opaque here.
sba_coalesce_chunks() may only presently fail if sba_alloc_range()
fails, which in turn only fails if the iommu is ou
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
vdma_alloc() may fail for different reasons, but since it only supports
indicating an error via a return of DMA_MAPPING_ERROR, we coalesce the
different reasons into -EIO as is documented on dma_map_sgta
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
So propagate the error from __s390_dma_map_sg() up. __s390_dma_map_sg()
returns either -ENOMEM on allocation failure or -EINVAL which is
the same as what's expected by dma_map_sgtable().
Signed-off-by:
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Niklas Schnelle
Cc: Gerald Schaefer
Cc: Heiko
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
Return -EINVAL if the ioc cannot be obtained.
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorpe
Cc: "James E.J. Bottomley"
Cc: Helge Deller
---
drivers/parisc/ccio-dma.c | 2 +-
drivers
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
Returning an errno from __sbus_iommu_map_sg() results in
sbus_iommu_map_sg_gflush() and sbus_iommu_map_sg_pflush() returning an
errno, as those functions are wrappers around __sbus_iommu_map_sg().
Signe
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
xen_swiotlb_map_sg() may only fail if xen_swiotlb_map_page() fails, but
xen_swiotlb_map_page() only supports returning errors as
DMA_MAPPING_ERROR. So coalesce all errors into EIO per the documentation
f
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav P
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
So make __dma_map_cont() return a valid errno (which is then propagated
to gart_map_sg() via dma_map_cont()) and return it in case of failure.
Also, return -EINVAL in case of invalid nents.
Signed-off-
Setting the ->dma_address to DMA_MAPPING_ERROR is not part of
the ->map_sg calling convention, so remove it.
Link: https://lore.kernel.org/linux-mips/20210716063241.gc13...@lst.de/
Suggested-by: Christoph Hellwig
Signed-off-by: Logan Gunthorpe
Cc: "David S. Miller"
Cc: Niklas Schnelle
Cc: Mich
From: Martin Oliveira
The .map_sg() op now expects an error code instead of zero on failure.
The only errno to return is -EINVAL in the case when DMA is not
supported.
Signed-off-by: Martin Oliveira
Signed-off-by: Logan Gunthorpe
---
kernel/dma/dummy.c | 2 +-
1 file changed, 1 insertion(+),
Hi,
This v3 of the series is spun out and expanded from my work to add
P2PDMA support to DMA map operations[1]. v2 is at [2]. The main changes
in v1 are to more carefully define the meaning of the error codes for
dma_map_sgtable().
The P2PDMA work requires distinguishing different error condition
Now that all the .map_sg operations have been converted to returning
proper error codes, drop the code to handle a zero return value,
add a warning if a zero is returned.
Signed-off-by: Logan Gunthorpe
---
kernel/dma/mapping.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff -
Convert to ssize_t return code so the return code from __iommu_map()
can be returned all the way down through dma_iommu_map_sg().
Signed-off-by: Logan Gunthorpe
Cc: Joerg Roedel
Cc: Will Deacon
---
drivers/iommu/iommu.c | 15 +++
include/linux/iommu.h | 22 +++---
2
Allow dma_map_sgtable() to pass errors from the map_sg() ops. This
will be required for returning appropriate error codes when mapping
P2PDMA memory.
Introduce __dma_map_sg_attrs() which will return the raw error code
from the map_sg operation (whether it be negative or zero). Then add a
dma_map_s
Now that the map_sg() op expects error codes instead of return zero on
error, convert dma_direct_map_sg() to return an error code. Per the
documentation for dma_map_sgtable(), -EIO is returned due to an
DMA_MAPPING_ERROR with unknown cause.
Signed-off-by: Logan Gunthorpe
---
kernel/dma/direct.c
Return appropriate error codes EINVAL or ENOMEM from
iommup_dma_map_sg(). If lower level code returns ENOMEM, then we
return it, other errors are coalesced into EINVAL.
iommu_dma_map_sg_swiotlb() returns -EIO as its an unknown error
from a call that returns DMA_MAPPING_ERROR.
Signed-off-by: Logan
On 7/29/2021 9:35 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jul 29, 2021 at 05:13:36PM +0100, Will Deacon wrote:
On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
next-20210723 was good. The boot failure seems to have
On Thu, Jul 29, 2021 at 05:13:36PM +0100, Will Deacon wrote:
> On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
> > On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
> > > next-20210723 was good. The boot failure seems to have been introduced
> > > with next-20210726.
On 2021-07-29 17:08, Heiko Stübner wrote:
Hi Dafna,
Am Donnerstag, 29. Juli 2021, 17:59:26 CEST schrieb Dafna Hirschfeld:
On 25.05.21 14:15, Benjamin Gaignard wrote:
@@ -879,7 +895,7 @@ static int rk_iommu_enable(struct rk_iommu *iommu)
for (i = 0; i < iommu->num_mmu; i++) {
Compiler is not happy about hidden declaration of intel_iommu_ops.
.../drivers/iommu/intel/iommu.c:414:24: warning: symbol 'intel_iommu_ops' was
not declared. Should it be static?
Move declaration to header file to make compiler happy.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/intel/dm
Kernel doc validator is unhappy with the following
.../perf.c:16: warning: Function parameter or member 'latency_lock' not
described in 'DEFINE_SPINLOCK'
.../perf.c:16: warning: expecting prototype for perf.c(). Prototype was for
DEFINE_SPINLOCK() instead
Drop kernel doc annotation since the to
On Wed, Jul 28, 2021 at 10:52:25AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> In Isolation VM with AMD SEV, bounce buffer needs to be accessed via
> extra address space which is above shared_gpa_boundary
> (E.G 39 bit address line) reported by Hyper-V CPUID ISOLATION_CONFIG.
> The access phy
On 2021-07-29 16:53, Heiko Stübner wrote:
Am Donnerstag, 29. Juli 2021, 17:43:07 CEST schrieb Robin Murphy:
On 2021-07-29 16:04, Heiko Stübner wrote:
Hi Robin,
Am Mittwoch, 28. Juli 2021, 17:58:21 CEST schrieb Robin Murphy:
Hi all,
Here's v2 where things start to look more realistic, hence t
On Wed, Jul 28, 2021 at 10:35:34AM -0700, Nathan Chancellor wrote:
> On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
> > next-20210723 was good. The boot failure seems to have been introduced with
> > next-20210726.
> >
> > I have attached the boot log.
>
> I noticed this with OpenS
Hi Dafna,
Am Donnerstag, 29. Juli 2021, 17:59:26 CEST schrieb Dafna Hirschfeld:
> On 25.05.21 14:15, Benjamin Gaignard wrote:
> > @@ -879,7 +895,7 @@ static int rk_iommu_enable(struct rk_iommu *iommu)
> >
> > for (i = 0; i < iommu->num_mmu; i++) {
> > rk_iommu_write(iommu->bases
On 7/29/21 8:02 AM, Tianyu Lan wrote:
>>
>
> There is x86_hyper_type to identify hypervisor type and we may check
> this variable after checking X86_FEATURE_HYPERVISOR.
>
> static inline bool hv_is_isolation_supported(void)
> {
> if (!cpu_feature_enabled(X86_FEATURE_HYPERVISOR))
> ret
On 25.05.21 14:15, Benjamin Gaignard wrote:
Add internal ops to be able to handle incoming variant v2.
The goal is to keep the overall structure of the framework but
to allow to add the evolution of this hardware block.
The ops are global for a SoC because iommu domains are not
attached to a
Am Donnerstag, 29. Juli 2021, 17:43:07 CEST schrieb Robin Murphy:
> On 2021-07-29 16:04, Heiko Stübner wrote:
> > Hi Robin,
> >
> > Am Mittwoch, 28. Juli 2021, 17:58:21 CEST schrieb Robin Murphy:
> >> Hi all,
> >>
> >> Here's v2 where things start to look more realistic, hence the expanded
> >> CC
Hi Robin,
Am Mittwoch, 28. Juli 2021, 17:58:21 CEST schrieb Robin Murphy:
> Hi all,
>
> Here's v2 where things start to look more realistic, hence the expanded
> CC list. The patches are now based on the current iommu/core branch to
> take John's iommu_set_dma_strict() cleanup into account.
>
>
On 2021-07-29 16:04, Heiko Stübner wrote:
Hi Robin,
Am Mittwoch, 28. Juli 2021, 17:58:21 CEST schrieb Robin Murphy:
Hi all,
Here's v2 where things start to look more realistic, hence the expanded
CC list. The patches are now based on the current iommu/core branch to
take John's iommu_set_dma_s
Hi Christoph:
Could you have a look at this patch and the following patch
"[PATCH 10/13] x86/Swiotlb: Add Swiotlb bounce buffer remap function
for HV IVM" These two patches follows your previous comments and add
dma_map_decrypted/dma_unmap_decrypted(). I don't add arch prefix because
each
On 7/29/2021 10:09 PM, Dave Hansen wrote:
On 7/29/21 6:01 AM, Tianyu Lan wrote:
On 7/29/2021 1:06 AM, Dave Hansen wrote:
On 7/28/21 7:52 AM, Tianyu Lan wrote:
@@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long
addr, int numpages, bool enc)
int ret;
/* Nothing t
On 7/28/21 8:22 AM, Christoph Hellwig wrote:
> On Tue, Jul 27, 2021 at 05:26:05PM -0500, Tom Lendacky via iommu wrote:
>> Introduce an x86 version of the prot_guest_has() function. This will be
>> used in the more generic x86 code to replace vendor specific calls like
>> sev_active(), etc.
>>
>> Wh
On 7/29/21 6:01 AM, Tianyu Lan wrote:
> On 7/29/2021 1:06 AM, Dave Hansen wrote:
>> On 7/28/21 7:52 AM, Tianyu Lan wrote:
>>> @@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long
>>> addr, int numpages, bool enc)
>>> int ret;
>>> /* Nothing to do if memory encryption is
On 7/29/2021 1:06 AM, Dave Hansen wrote:
On 7/28/21 7:52 AM, Tianyu Lan wrote:
@@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long addr, int
numpages, bool enc)
int ret;
/* Nothing to do if memory encryption is not active */
- if (!mem_encrypt_active())
+
Hi Dave:
Thanks for your review.
On 7/28/2021 11:29 PM, Dave Hansen wrote:
On 7/28/21 7:52 AM, Tianyu Lan wrote:
@@ -1986,7 +1988,9 @@ static int __set_memory_enc_dec(unsigned long addr, int
numpages, bool enc)
int ret;
/* Nothing to do if memory encryption is not active */
On 2021/7/29 17:36, Robin Murphy wrote:
On 2021-07-29 08:13, Lu Baolu wrote:
Hi Robin,
On 7/28/21 11:58 PM, Robin Murphy wrote:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 982545234cf3..eecb5657de69 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -136,6 +
On 2021-07-29 03:55, chenxiang (M) wrote:
Hi Robin,
在 2021/7/28 23:58, Robin Murphy 写道:
Hi all,
Here's v2 where things start to look more realistic, hence the expanded
CC list. The patches are now based on the current iommu/core branch to
take John's iommu_set_dma_strict() cleanup into accoun
Hi, Stefano!
> I don't know on which platform Roman Skakun (CC'ed) found the problem.
> But if we look at arch/arm/mm/dma-mapping.c:__dma_alloc, one of the
> possible options is the "remap_allocator", which calls
> __alloc_remap_buffer, which calls dma_common_contiguous_remap, which
> calls vmap.
On Thu, Jul 29, 2021 at 5:00 PM Greg KH wrote:
>
> On Thu, Jul 29, 2021 at 03:35:02PM +0800, Xie Yongji wrote:
> > +/*
> > + * The basic configuration of a VDUSE device, which is used by
> > + * VDUSE_CREATE_DEV ioctl to create a VDUSE device.
> > + */
> > +struct vduse_dev_config {
>
> Please doc
On Fri, 23 Jul 2021 14:40:26 PDT (-0700), Atish Patra wrote:
RISC-V privilege specification doesn't define an IOMMU or any method modify
PMA attributes or PTE entries to allow non-coherent mappings yet. In
the beginning, this approach was adopted assuming that most of the RISC-V
platforms would s
> On 28-Jul-2021, at 11:05 PM, Nathan Chancellor wrote:
>
> On Wed, Jul 28, 2021 at 01:31:06PM +0530, Sachin Sant wrote:
>> linux-next fails to boot on Power server (POWER8/POWER9). Following traces
>> are seen during boot
>>
>> [0.010799] software IO TLB: tearing down default memory pool
> -Original Message-
> From: Christoph Hellwig
> Sent: Monday, July 12, 2021 1:17 AM
> To: iommu@lists.linux-foundation.org; Russell King
;
> Brian Cain
> Cc: Dillon Min ; Vladimir Murzin
> ; linux-arm-ker...@lists.infradead.org; linux-
> hexa...@vger.kernel.org; linux-ker...@vger.kern
On 2021-07-29 08:13, Lu Baolu wrote:
Hi Robin,
On 7/28/21 11:58 PM, Robin Murphy wrote:
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 982545234cf3..eecb5657de69 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -136,6 +136,9 @@ static int __init iommu_subsys_i
On 28/07/2021 16:58, Robin Murphy wrote:
When passthrough is enabled, the default strictness policy becomes
irrelevant, since any subsequent runtime override to a DMA domain type
now embodies an explicit choice of strictness as well. Save on noise by
only logging the default policy when it is mea
On Thu, Jul 29, 2021 at 03:35:02PM +0800, Xie Yongji wrote:
> +/*
> + * The basic configuration of a VDUSE device, which is used by
> + * VDUSE_CREATE_DEV ioctl to create a VDUSE device.
> + */
> +struct vduse_dev_config {
Please document this structure using kernel doc so we know what all the
fie
VDUSE (vDPA Device in Userspace) is a framework to support
implementing software-emulated vDPA devices in userspace. This
document is intended to clarify the VDUSE design and usage.
Signed-off-by: Xie Yongji
---
Documentation/userspace-api/index.rst | 1 +
Documentation/userspace-api/vduse.rst
This VDUSE driver enables implementing software-emulated vDPA
devices in userspace. The vDPA device is created by
ioctl(VDUSE_CREATE_DEV) on /dev/vduse/control. Then a char device
interface (/dev/vduse/$NAME) is exported to userspace for device
emulation.
In order to make the device emulation more
This implements an MMU-based software IOTLB to support mapping
kernel dma buffer into userspace dynamically. The basic idea
behind it is treating MMU (VA->PA) as IOMMU (IOVA->PA). The
software IOTLB will set up MMU mapping instead of IOMMU mapping
for the DMA transfer so that the userspace process
This patch introduces an attribute for vDPA device to indicate
whether virtual address can be used. If vDPA device driver set
it, vhost-vdpa bus driver will not pin user page and transfer
userspace virtual address instead of physical address during
DMA mapping. And corresponding vma->vm_file and of
The upcoming patch is going to support VA mapping/unmapping.
So let's factor out the logic of PA mapping/unmapping firstly
to make the code more readable.
Suggested-by: Jason Wang
Signed-off-by: Xie Yongji
Acked-by: Jason Wang
---
drivers/vhost/vdpa.c | 55 +
Add an opaque pointer for DMA mapping.
Suggested-by: Jason Wang
Signed-off-by: Xie Yongji
Acked-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 6 +++---
drivers/vhost/vdpa.c | 2 +-
include/linux/vdpa.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
di
Add an opaque pointer for vhost IOTLB. And introduce
vhost_iotlb_add_range_ctx() to accept it.
Suggested-by: Jason Wang
Signed-off-by: Xie Yongji
Acked-by: Jason Wang
---
drivers/vhost/iotlb.c | 20
include/linux/vhost_iotlb.h | 3 +++
2 files changed, 19 insertions
The device reset may fail in virtio-vdpa case now, so add checks to
its return value and fail the register_virtio_device().
Signed-off-by: Xie Yongji
---
drivers/virtio/virtio.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/virtio/virtio.c b/drivers
The vpda_reset() may fail now. This adds check to its return
value and fail the virtio_vdpa_reset().
Signed-off-by: Xie Yongji
---
drivers/virtio/virtio_vdpa.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c
index
This adds a return value to reset function so that we can
handle the reset failure later. No functional changes.
Signed-off-by: Xie Yongji
---
arch/um/drivers/virtio_uml.c | 4 +++-
drivers/platform/mellanox/mlxbf-tmfifo.c | 4 +++-
drivers/remoteproc/remoteproc_virtio.c | 4 +++-
We don't need to set FAILED status bit on device index allocation
failure since the device initialization hasn't been started yet.
This doesn't affect runtime, found in code review.
Signed-off-by: Xie Yongji
---
drivers/virtio/virtio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The vdpa_reset() may fail now. This adds check to its return
value and fail the vhost_vdpa_open().
Signed-off-by: Xie Yongji
---
drivers/vhost/vdpa.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index dd05c1e1133c..9a00b
Re-read the device status to ensure it's set to zero during
resetting. Otherwise, fail the vhost_vdpa_set_status() after timeout.
Signed-off-by: Xie Yongji
---
drivers/vhost/vdpa.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhos
Re-read the device status to ensure it's set to zero during
resetting. Otherwise, fail the vdpa_reset() after timeout.
Signed-off-by: Xie Yongji
---
include/linux/vdpa.h | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.
Use tabs to indent the code instead of spaces.
Signed-off-by: Xie Yongji
---
include/linux/vdpa.h | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 7c49bc5a2b71..406d53a606ac 100644
--- a/include/
1 - 100 of 104 matches
Mail list logo
