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, but
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, but isn't supported at the moment. In
On 04/09/2018 03:12, Xu Zaibo wrote:
> 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
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 the
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 the series doesn't provide support for SVA
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 consider why the
Hi Zaibo,
On 27/08/18 09:06, Xu Zaibo wrote:
>> +struct vfio_iommu_type1_bind_process {
>> + __u32 flags;
>> +#define VFIO_IOMMU_BIND_PID (1 << 0)
>> + __u32 pasid;
> As I am doing some works on the SVA patch set. I just consider why the
> user space need this pasid.
> Maybe,
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/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
(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)
On 26/05/18 04:53, Xu Zaibo wrote:
> I guess there may be some misunderstandings :).
>
> From the current patches, 'iommu_sva_device_shutdown' is called
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,
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, group->sva_enabled will be true
so we
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, while I
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, while I create mediated devices based on one parent
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 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;
>> + struct vfio_iommu_sva_bind_data data
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
On 17/05/18 16:58, Jonathan Cameron 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;
>> +struct
On Fri, 11 May 2018 20:06:14 +0100
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
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 order to access the process' address space.
The
20 matches
Mail list logo