On 2020/4/30 22:34, Jean-Philippe Brucker wrote:
Some devices can tag their DMA requests with a 20-bit Process Address
Space ID (PASID), allowing them to access multiple address spaces. In
combination with recoverable I/O page faults (for example PCIe PRI),
PASID allows the IOMMU to share page
Hi,
On 2020/2/25 2:23, Jean-Philippe Brucker wrote:
From: Jean-Philippe Brucker
The SMMU provides a Stall model for handling page faults in platform
devices. It is similar to PCI PRI, but doesn't require devices to have
their own translation cache. Instead, faulting transactions are parked
Hi,
On 2020/2/25 17:25, Jean-Philippe Brucker wrote:
Hi Zaibo,
On Tue, Feb 25, 2020 at 11:30:05AM +0800, Xu Zaibo wrote:
+struct iopf_queue *
+iopf_queue_alloc(const char *name, iopf_queue_flush_t flush, void *cookie)
+{
+ struct iopf_queue *queue;
+
+ queue = kzalloc(sizeof(*queue
Hi,
On 2020/2/25 16:33, zhangfei wrote:
Hi, Zaibo
On 2020/2/24 下午3:17, Xu Zaibo wrote:
@@ -585,6 +595,13 @@ void uacce_remove(struct uacce_device *uacce)
cdev_device_del(uacce->cdev, >dev);
xa_erase(_xa, uacce->dev_id);
put_device(>dev);
+
+/*
+
Hi,
On 2020/2/25 2:23, Jean-Philippe Brucker wrote:
From: Jean-Philippe Brucker
Some systems allow devices to handle I/O Page Faults in the core mm. For
example systems implementing the PCI PRI extension or Arm SMMU stall
model. Infrastructure for reporting these recoverable page faults was
Hi Zhangfei,
On 2020/2/24 15:06, Zhangfei Gao wrote:
When uacce parent device module is removed, user app may
still keep the mmaped area, which can be accessed unsafely.
When rmmod, Parent device drvier will call uacce_remove,
which unmap all remaining mapping from user space for safety.
Hi,
Is this solution trying to support general user space processes who
are directly working on devices?
Yes, it is.
Okay. But I got another question. As I write a Crypto driver, could I
call 'mdev_register_device'?
Or in other words, is 'mdev_register_device' acceptable for drivers of
Hi,
Is this solution trying to support general user space processes who are
directly working on devices?
Thanks,
Zaibo
.
On 2018/11/5 15:34, Lu Baolu wrote:
Hi,
The Mediate Device is a framework for fine-grained physical device
sharing across the isolated domains. Currently the mdev
Hi Jean,
On 2018/10/20 2:11, Jean-Philippe Brucker wrote:
This is a first prototype adding auxiliary domain support to Arm SMMUv3,
following Lu Baolu's latest proposal for IOMMU aware mediated devices
[1]. It works, but the attach() API still doesn't feel right. See (2)
below.
Patch 1 adapts
Hi,
On 2018/10/16 9:21, Lu Baolu wrote:
Hi,
On 10/15/2018 04:50 PM, Xu Zaibo wrote:
Hi,
On 2018/10/15 10:48, Lu Baolu wrote:
Hi,
On 10/13/2018 04:25 PM, Xu Zaibo wrote:
Hi,
On 2018/10/12 13:16, Lu Baolu wrote:
Hi,
The Mediate Device is a framework for fine-grained physical device
Hi,
On 2018/10/15 10:48, Lu Baolu wrote:
Hi,
On 10/13/2018 04:25 PM, Xu Zaibo wrote:
Hi,
On 2018/10/12 13:16, Lu Baolu wrote:
Hi,
The Mediate Device is a framework for fine-grained physical device
sharing across the isolated domains. Currently the mdev framework
is designed
Hi,
On 2018/10/12 13:16, Lu Baolu wrote:
Hi,
The Mediate Device is a framework for fine-grained physical device
sharing across the isolated domains. Currently the mdev framework
is designed to be independent of the platform IOMMU support. As the
result, the DMA isolation relies on the mdev
On 2018/9/5 19:02, Jean-Philippe Brucker wrote:
On 05/09/2018 04:15, Xu Zaibo wrote:
1. While the series are finished well, VFIO-PCI device can be held
by only one process
through binding IOCTL command without PASID (without PASID
being exposed user space).
It could
On 2018/9/3 18:34, Jean-Philippe Brucker wrote:
On 01/09/18 03:23, Xu Zaibo wrote:
As one application takes a whole function while using VFIO-PCI, why do
the application and the
function need to enable PASID capability? (Since just one I/O page table
is enough for them.)
At the moment
Hi Jean,
On 2018/8/31 21:34, Jean-Philippe Brucker wrote:
On 27/08/18 09:06, Xu Zaibo wrote:
+struct vfio_iommu_type1_bind_process {
+__u32flags;
+#define VFIO_IOMMU_BIND_PID(1 << 0)
+__u32pasid;
As I am doing some works on the SVA patch set. I just consid
Hi Jean,
On 2018/5/12 3:06, Jean-Philippe Brucker wrote:
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 1aa7b82e8169..dc07752c8fe8 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -665,6 +665,82 @@ struct vfio_iommu_type1_dma_unmap {
#define
Hi,
On 2018/8/2 18:10, Alan Cox wrote:
One motivation I guess, is that most accelerators lack of a
well-abstracted high level APIs similar to GPU side (e.g. OpenCL
clearly defines Shared Virtual Memory models). VFIO mdev
might be an alternative common interface to enable SVA usages
on various
Hi,
On 2018/5/29 19:55, Jean-Philippe Brucker wrote:
(If possible, please reply in plain text to the list. Reading this in a
text-only reader is confusing, because all quotes have the same level)
Sorry for that， I have reset the thunderbird, :) thanks.
On 26/05/18 04:53, Xu Zaibo wrote:
I
Hi,
On 2018/5/25 17:47, Jean-Philippe Brucker wrote:
On 25/05/18 03:39, Xu Zaibo wrote:
Hi,
On 2018/5/24 23:04, Jean-Philippe Brucker wrote:
On 24/05/18 13:35, Xu Zaibo wrote:
Right, sva_init() must be called once for any device that intends to use
bind(). For the second process though
Hi,
On 2018/5/24 23:04, Jean-Philippe Brucker wrote:
On 24/05/18 13:35, Xu Zaibo wrote:
Right, sva_init() must be called once for any device that intends to use
bind(). For the second process though, group->sva_enabled will be true
so we won't call sva_init() again, only bind().
Well, whil
On 2018/5/24 19:44, Jean-Philippe Brucker wrote:
Hi,
On 23/05/18 10:38, Xu Zaibo wrote:
+static int vfio_iommu_bind_group(struct vfio_iommu *iommu,
+ struct vfio_group *group,
+ struct vfio_mm *vfio_mm)
+{
+int ret;
+bool enabled_sva = false
Hi,
On 2018/5/12 3:06, Jean-Philippe Brucker wrote:
Add two new ioctls for VFIO containers. VFIO_IOMMU_BIND_PROCESS creates a
bond between a container and a process address space, identified by a
Process Address Space ID (PASID). Devices in the container append this
PASID to DMA transactions in
tweaks the iommu_fault_event and page_response_msg to
extend the fault id field. Stall uses 16 bits of IDs whereas PCI PRI only
uses 9.
For PCIe devices without ATC, can they use this Stall model?
Thanks.
Xu Zaibo
Signed-off-by: Jean-Philippe Brucker <jean-philippe.bruc...@arm.com>
---
d
23 matches
Mail list logo
