On Wed, Mar 31, 2021 at 11:59 AM Geert Uytterhoeven
wrote:
> While long fancy messages have a higher probability of being seen than
> small messages, they may scroll of the screen fast, if visible at all,
> and may still be missed. In addition, they increase boot time and
> kernel size.
>
> The
The Intel IOMMU driver reports the DMA fault reason in a decimal number
while the VT-d specification uses a hexadecimal one. It's inconvenient
that users need to covert them everytime before consulting the spec.
Let's use hexadecimal number for a DMA fault reason.
The fault message uses
Current VT-d implementation supports nested translation only if all
underlying IOMMUs support the nested capability. This is unnecessary
as the upper layer is allowed to create different containers and set
them with different type of iommu backend. The IOMMU driver needs to
guarantee that devices
Hi all,
The VFIO part is at here:
https://lore.kernel.org/kvm/20210507103608.39440-1-zhukeqi...@huawei.com/
Thanks,
Keqian
On 2021/5/7 18:21, Keqian Zhu wrote:
> Hi Robin, Will and everyone,
>
> I think this series is relative mature now, please give your valuable
> suggestions,
> thanks!
>
On Mon, May 17, 2021 at 10:35:00AM -0300, Jason Gunthorpe wrote:
> Well, I'm sorry, but there is a huge other thread talking about the
> IOASID design in great detail and why this is all needed. Jumping into
> this thread without context and basically rejecting all the
> conclusions that were
From: Xingang Wang
When booting with devicetree, the pci_request_acs() is called after the
enumeration and initialization of PCI devices, thus the ACS is not
enabled. This patch add check for IOMMU in of_core_init(), and call
pci_request_acs() when iommu is detected, making sure that the ACS
On Mon, May 17, 2021 at 02:53:16PM +0200, Joerg Roedel wrote:
> On Mon, May 17, 2021 at 09:30:10AM -0300, Jason Gunthorpe wrote:
> > On Mon, May 17, 2021 at 02:22:06PM +0200, Joerg Roedel wrote:
> > > Yes, I know, We have the AUX-domain specific functions now, but I
> > > suggested a while back to
On Thu, May 13, 2021 at 04:40:28PM -0700, Jacob Pan wrote:
> Looks like we are converging. Let me summarize the takeaways:
> 1. Remove IOMMU_SVA_BIND_SUPERVISOR flag from this patch, in fact there
> will be no flags at all for iommu_sva_bind_device()
> 2. Remove all supervisor SVA related vt-d,
Hi Benjamin,
Am Freitag, 7. Mai 2021, 11:02:32 CEST schrieb Benjamin Gaignard:
> From: Simon Xue
>
> RK356x SoC got new IOMMU hardware block (version 2).
> Add a compatible to distinguish it from the first version.
>
> Signed-off-by: Simon Xue
> [Benjamin]
> - port driver from kernel 4.19 to
+cc iommu list.
Christoph Biedl 于2021年5月17日周一 下午1:52写道：
>
> Christoph Biedl wrote...
>
> > Thanks for taking care, unfortunately no improvement with 5.10.38-rc1 here.
>
> So in case this is related to the .config, I'm attaching it. Hardware is,
> as said before, an old Thinkpad x200, vendor BIOS
Christoph Biedl 于2021年5月17日周一 下午2:25写道：
>
> Jack Wang wrote...
>
> > Christoph Biedl 于2021年5月17日周一
> > 下午1:52写道：
> > >
> > > Christoph Biedl wrote...
> > >
> > > > Thanks for taking care, unfortunately no improvement with 5.10.38-rc1
> > > > here.
> > >
> > > So in case this is related to the
On Mon, May 17, 2021 at 02:45:01PM +0200, Jack Wang wrote:
> Christoph Biedl 于2021年5月17日周一 下午2:25写道：
> >
> > Jack Wang wrote...
> >
> > > Christoph Biedl 于2021年5月17日周一
> > > 下午1:52写道：
> > > >
> > > > Christoph Biedl wrote...
> > > >
> > > > > Thanks for taking care, unfortunately no improvement
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
This implements an MMU-based IOMMU driver to support mapping
kernel dma buffer into userspace. The basic idea behind it is
treating MMU (VA->PA) as IOMMU (IOVA->PA). The driver will set
up MMU mapping instead of IOMMU mapping for the DMA transfer so
that the userspace process is able to use its
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 +
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(-)
This VDUSE driver enables implementing vDPA devices in userspace.
Both control path and data path of vDPA devices will be able to
be handled in userspace.
In the control path, the VDUSE driver will make use of message
mechnism to forward the config operation from vdpa bus driver
to userspace.
This series introduces a framework, which can be used to implement
vDPA Devices in a userspace program. The work consist of two parts:
control path forwarding and data path offloading.
In the control path, the VDUSE driver will make use of message
mechnism to forward the config operation from
Export alloc_iova_fast() so that some modules can use it
to improve iova allocation efficiency.
Signed-off-by: Xie Yongji
---
drivers/iommu/iova.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index e6e2fa85271c..317eef64ffef 100644
---
This ensures that the residual bytes in response (might come
from an untrusted device) will not exceed the data buffer length.
Signed-off-by: Xie Yongji
---
drivers/scsi/virtio_scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c
Export receive_fd() so that some modules can use
it to pass file descriptor between processes without
missing any security stuffs.
Signed-off-by: Xie Yongji
---
fs/file.c| 6 ++
include/linux/file.h | 7 +++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git
This ensures that we will not use an invalid block size
in config space (might come from an untrusted device).
Signed-off-by: Xie Yongji
---
drivers/block/virtio_blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
Increase the recursion depth of eventfd_signal() to 1. This
is the maximum recursion depth we have found so far, which
can be triggered with the following call chain:
kvm_io_bus_write[kvm]
--> ioeventfd_write [kvm]
--> eventfd_signal
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
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 | 53
On Mon, May 17, 2021 at 09:30:10AM -0300, Jason Gunthorpe wrote:
> On Mon, May 17, 2021 at 02:22:06PM +0200, Joerg Roedel wrote:
> > Yes, I know, We have the AUX-domain specific functions now, but I
> > suggested a while back to turn the mdev code into its own bus
> > implementation and let the
On Wed, May 12, 2021 at 07:46:05AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, May 12, 2021 1:37 AM
> >
> > On Tue, May 11, 2021 at 02:56:05PM +0800, Lu Baolu wrote:
> >
> > > > After my next series the mdev drivers will have direct access to
> > > > the
On Fri, May 14, 2021 at 10:31:43AM -0300, Jason Gunthorpe wrote:
> There is no place for "domain as a carrier of PASID"
> there. mdev_device should NOT participate in the IOMMU layer because
> it is NOT a HW device. Trying to warp mdev_device into an IOMMU
> presence is already the source of a lot
Hi Jean-Philippe,
On Fri, Apr 23, 2021 at 01:38:31PM +0200, Jean-Philippe Brucker wrote:
> Jean-Philippe Brucker (6):
> ACPI: arm64: Move DMA setup operations out of IORT
> ACPI: Move IOMMU setup code out of IORT
> ACPI: Add driver for the VIOT table
> iommu/dma: Pass address limit rather
On Mon, May 17, 2021 at 02:22:06PM +0200, Joerg Roedel wrote:
> On Fri, May 14, 2021 at 10:31:43AM -0300, Jason Gunthorpe wrote:
> > There is no place for "domain as a carrier of PASID"
> > there. mdev_device should NOT participate in the IOMMU layer because
> > it is NOT a HW device. Trying to
Jack Wang wrote...
> Christoph Biedl 于2021年5月17日周一 下午1:52写道：
> >
> > Christoph Biedl wrote...
> >
> > > Thanks for taking care, unfortunately no improvement with 5.10.38-rc1
> > > here.
> >
> > So in case this is related to the .config, I'm attaching it. Hardware is,
> > as said before, an old
Greg KH wrote...
> On Mon, May 17, 2021 at 02:45:01PM +0200, Jack Wang wrote:
> > So it's caused by this commit[1], and it should be fixed by latest
> > 5.10.38-rc1
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=linux-5.10.y
> >
On Tue, May 18, 2021 at 12:30:15AM +0200, Christoph Biedl wrote:
> Greg KH wrote...
>
> > On Mon, May 17, 2021 at 02:45:01PM +0200, Jack Wang wrote:
>
> > > So it's caused by this commit[1], and it should be fixed by latest
> > > 5.10.38-rc1
> > >
33 matches
Mail list logo
