[PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
Mediated device only uses IOMMU APIs, the underlying hardware can be
managed by an IOMMU domain.
Aim of this change is:
- To use most of the code of TYPE1 IOMMU driver for mediated devices
- To support direct assigned device and mediated device in single module
This change adds pin and unpin support for mediated device to TYPE1 IOMMU
backend module. More details:
- vfio_pin_pages() callback here uses task and address space of vfio_dma,
that is, of the process who mapped that iova range.
- Added pfn_list tracking logic to address space structure. All pages
pinned through this interface are trached in its address space.
- Pinned pages list is used to verify unpinning request and to unpin
remaining pages while detaching the group for that device.
- Page accounting is updated to account in its address space where the
pages are pinned/unpinned.
- Accouting for mdev device is only done if there is no iommu capable
domain in the container. When there is a direct device assigned to the
container and that domain is iommu capable, all pages are already pinned
during DMA_MAP.
- Page accouting is updated on hot plug and unplug mdev device and pass
through device.
Tested by assigning below combinations of devices to a single VM:
- GPU pass through only
- vGPU device only
- One GPU pass through and one vGPU device
- Linux VM hot plug and unplug vGPU device while GPU pass through device
exist
- Linux VM hot plug and unplug GPU pass through device while vGPU device
exist
Signed-off-by: Kirti Wankhede
Signed-off-by: Neo Jia
Change-Id: I295d6f0f2e0579b8d9882bfd8fd5a4194b97bd9a
---
drivers/vfio/vfio_iommu_type1.c | 538 +---
1 file changed, 500 insertions(+), 38 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 8d64528dcc22..e511073446a0 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#define DRIVER_VERSION "0.2"
#define DRIVER_AUTHOR "Alex Williamson "
@@ -56,6 +57,7 @@ MODULE_PARM_DESC(disable_hugepages,
struct vfio_iommu {
struct list_headdomain_list;
struct list_headaddr_space_list;
+ struct vfio_domain *external_domain; /* domain for external user */
struct mutexlock;
struct rb_root dma_list;
boolv2;
@@ -67,6 +69,9 @@ struct vfio_addr_space {
struct mm_struct*mm;
struct list_headnext;
atomic_tref_count;
+ /* external user pinned pfns */
+ struct rb_root pfn_list; /* pinned Host pfn list */
+ struct mutexpfn_list_lock; /* mutex for pfn_list */
};
struct vfio_domain {
@@ -83,6 +88,7 @@ struct vfio_dma {
unsigned long vaddr; /* Process virtual addr */
size_t size; /* Map size (bytes) */
int prot; /* IOMMU_READ/WRITE */
+ booliommu_mapped;
struct vfio_addr_space *addr_space;
struct task_struct *task;
boolmlock_cap;
@@ -94,6 +100,19 @@ struct vfio_group {
};
/*
+ * Guest RAM pinning working set or DMA target
+ */
+struct vfio_pfn {
+ struct rb_node node;
+ unsigned long pfn;/* Host pfn */
+ int prot;
+ atomic_tref_count;
+};
+
+#define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)\
+ (!list_empty(&iommu->domain_list))
+
+/*
* This code handles mapping and unmapping of user data buffers
* into DMA'ble space using the IOMMU
*/
@@ -153,6 +172,93 @@ static struct vfio_addr_space *vfio_find_addr_space(struct
vfio_iommu *iommu,
return NULL;
}
+/*
+ * Helper Functions for host pfn list
+ */
+static struct vfio_pfn *vfio_find_pfn(struct vfio_addr_space *addr_space,
+ unsigned long pfn)
+{
+ struct vfio_pfn *vpfn;
+ struct rb_node *node = addr_space->pfn_list.rb_node;
+
+ while (node) {
+ vpfn = rb_entry(node, struct vfio_pfn, node);
+
+ if (pfn < vpfn->pfn)
+ node = node->rb_left;
+ else if (pfn > vpfn->pfn)
+ node = node->rb_right;
+ else
+ return vpfn;
+ }
+
+ return NULL;
+}
+
+static void vfio_link_pfn(struct vfio_addr_space *addr_space,
+ struct vfio_pfn *new)
+{
+ struct rb_node **link, *parent = NULL;
+ struct vfio_pfn *vpfn;
+
+ link = &addr_space->pfn_list.rb_node;
+ while (*link) {
+ parent = *link;
+ vpfn = rb_entry(parent, struct vfio_pfn, node
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On 05/11/16 08:10, Kirti Wankhede wrote: > VFIO IOMMU drivers are designed for the devices which are IOMMU capable. > Mediated device only uses IOMMU APIs, the underlying hardware can be > managed by an IOMMU domain. > > Aim of this change is: > - To use most of the code of TYPE1 IOMMU driver for mediated devices > - To support direct assigned device and mediated device in single module > > This change adds pin and unpin support for mediated device to TYPE1 IOMMU > backend module. More details: > - vfio_pin_pages() callback here uses task and address space of vfio_dma, > that is, of the process who mapped that iova range. > - Added pfn_list tracking logic to address space structure. All pages > pinned through this interface are trached in its address space. > - Pinned pages list is used to verify unpinning request and to unpin > remaining pages while detaching the group for that device. > - Page accounting is updated to account in its address space where the > pages are pinned/unpinned. > - Accouting for mdev device is only done if there is no iommu capable > domain in the container. When there is a direct device assigned to the > container and that domain is iommu capable, all pages are already pinned > during DMA_MAP. > - Page accouting is updated on hot plug and unplug mdev device and pass > through device. > > Tested by assigning below combinations of devices to a single VM: > - GPU pass through only This does not require this patchset, right? > - vGPU device only Out of curiosity - how exactly did you test this? The exact GPU, how to create vGPU, what was the QEMU command line and the guest does with this passed device? Thanks. -- Alexey
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On 11/8/2016 4:46 AM, Alex Williamson wrote:
> On Sat, 5 Nov 2016 02:40:44 +0530
> Kirti Wankhede wrote:
>
...
>> -static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)
>> +static int __vfio_pin_page_external(struct vfio_dma *dma, unsigned long
>> vaddr,
>> +int prot, unsigned long *pfn_base,
>> +bool do_accounting)
>> +{
>> +struct task_struct *task = dma->task;
>> +unsigned long limit = task_rlimit(task, RLIMIT_MEMLOCK) >> PAGE_SHIFT;
>> +bool lock_cap = dma->mlock_cap;
>> +struct mm_struct *mm = dma->addr_space->mm;
>> +int ret;
>> +bool rsvd;
>> +
>> +ret = vaddr_get_pfn(mm, vaddr, prot, pfn_base);
>> +if (ret)
>> +return ret;
>> +
>> +rsvd = is_invalid_reserved_pfn(*pfn_base);
>> +
>> +if (!rsvd && !lock_cap && mm->locked_vm + 1 > limit) {
>> +put_pfn(*pfn_base, prot);
>> +pr_warn("%s: Task %s (%d) RLIMIT_MEMLOCK (%ld) exceeded\n",
>> +__func__, task->comm, task_pid_nr(task),
>> +limit << PAGE_SHIFT);
>> +return -ENOMEM;
>> +}
>> +
>> +if (!rsvd && do_accounting)
>> +vfio_lock_acct(mm, 1);
>> +
>> +return 1;
>> +}
>> +
>> +static void __vfio_unpin_page_external(struct vfio_addr_space *addr_space,
>> + unsigned long pfn, int prot,
>> + bool do_accounting)
>> +{
>> +put_pfn(pfn, prot);
>> +
>> +if (do_accounting)
>> +vfio_lock_acct(addr_space->mm, -1);
>
> Can't we batch this like we do elsewhere? Intel folks, AIUI you intend
> to pin all VM memory through this side channel, have you tested the
> scalability and performance of this with larger VMs? Our vfio_pfn
> data structure alone is 40 bytes per pinned page, which means for
> each 1GB of VM memory, we have 10MBs worth of struct vfio_pfn!
> Additionally, unmapping each 1GB of VM memory will result in 256k
> separate vfio_lock_acct() callbacks. I'm concerned that we're not
> being efficient enough in either space or time.
>
> One thought might be whether we really need to save the pfn, we better
> always get the same result if we pin it again, or maybe we can just do
> a lookup through the mm at that point without re-pinning. Could we get
> to the point where we only need an atomic_t ref count per page in a
> linear array relative to the IOVA?
Ok. Is System RAM hot-plug supported? How is system RAM hot-plug
handled? Are there DMA_MAP calls on such hot-plug for additional range?
If we have a linear array/memory, we will have to realloc it on memory
hot-plug?
> That would give us 1MB per 1GB
> overhead. The semantics of the pin and unpin would make more sense then
> too, both would take an IOVA range, only pinning would need a return
> mechanism. For instance:
>
> int pin_pages(void *iommu_data, dma_addr_t iova_base,
> int npage, unsigned long *pfn_base);
>
> This would pin physically contiguous pages up to npage, returning the
> base pfn and returning the number of pages pinned (<= npage). The
> vendor driver would make multiple calls to fill the necessary range.
With the current patch, input is user_pfn[] array and npages.
int vfio_pin_pages(struct device *dev, unsigned long *user_pfn,
int npage, int prot, unsigned long *phys_pfn)
When guest allocates memory with malloc(), gfns would not be contiguous,
right? These gfns (user_pfns) are passed as argument here.
Is there any case where we could get pin/unpin request for contiguous pages?
> Unpin would then simply be:
>
> void unpin_pages(void *iommu_data, dma_addr_t iova_base, int npage);
>
> Hugepage usage would really make such an interface shine (ie. 2MB+
> contiguous ranges). A downside would be the overhead of getting the
> group and container reference in vfio for each callback, perhaps we'd
> need to figure out how the vendor driver could hold that reference.
In very initial phases of proposal, I had suggested to keep pointer to
container->iommu_data in struct mdev_device. But that was discarded.
> The current API of passing around pfn arrays, further increasing the
> overhead of the whole ecosystem just makes me cringe though.
>
...
>> +if (ret <= 0) {
>> +WARN_ON(!ret);
>> +goto pin_unwind;
>> +}
>> +
>> +mutex_lock(&dma->addr_space->pfn_list_lock);
>> +
>> +/* search if pfn exist */
>> +p = vfio_find_pfn(dma->addr_space, pfn[i]);
>> +if (p) {
>> +atomic_inc(&p->ref_count);
>
> We never test whether (p->prot == prot), shouldn't we be doing
> something in that case? In fact, why do we allow the side-channel
> through the .{un}pin_pages to specify page protection flags that might
> be different than the user specified for the DMA_MAP? If the user
> specified read-only, the vendor
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On Tue, 08 Nov 2016 10:20:14 +0800
Jike Song wrote:
> On 11/08/2016 07:16 AM, Alex Williamson wrote:
> > On Sat, 5 Nov 2016 02:40:44 +0530
> > Kirti Wankhede wrote:
> >
> >> VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
> >> Mediated device only uses IOMMU APIs, the underlying hardware can be
> >> managed by an IOMMU domain.
> >>
> >> Aim of this change is:
> >> - To use most of the code of TYPE1 IOMMU driver for mediated devices
> >> - To support direct assigned device and mediated device in single module
> >>
> >> This change adds pin and unpin support for mediated device to TYPE1 IOMMU
> >> backend module. More details:
> >> - vfio_pin_pages() callback here uses task and address space of vfio_dma,
> >> that is, of the process who mapped that iova range.
> >> - Added pfn_list tracking logic to address space structure. All pages
> >> pinned through this interface are trached in its address space.
> > ^ k
> > --|
> >
> >> - Pinned pages list is used to verify unpinning request and to unpin
> >> remaining pages while detaching the group for that device.
> >> - Page accounting is updated to account in its address space where the
> >> pages are pinned/unpinned.
> >> - Accouting for mdev device is only done if there is no iommu capable
> >> domain in the container. When there is a direct device assigned to the
> >> container and that domain is iommu capable, all pages are already pinned
> >> during DMA_MAP.
> >> - Page accouting is updated on hot plug and unplug mdev device and pass
> >> through device.
> >>
> >> Tested by assigning below combinations of devices to a single VM:
> >> - GPU pass through only
> >> - vGPU device only
> >> - One GPU pass through and one vGPU device
> >> - Linux VM hot plug and unplug vGPU device while GPU pass through device
> >> exist
> >> - Linux VM hot plug and unplug GPU pass through device while vGPU device
> >> exist
> >>
> >> Signed-off-by: Kirti Wankhede
> >> Signed-off-by: Neo Jia
> >> Change-Id: I295d6f0f2e0579b8d9882bfd8fd5a4194b97bd9a
> >> ---
> >> drivers/vfio/vfio_iommu_type1.c | 538
> >> +---
> >> 1 file changed, 500 insertions(+), 38 deletions(-)
> >>
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c
> >> b/drivers/vfio/vfio_iommu_type1.c
> >> index 8d64528dcc22..e511073446a0 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++ b/drivers/vfio/vfio_iommu_type1.c
> >> @@ -36,6 +36,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #define DRIVER_VERSION "0.2"
> >> #define DRIVER_AUTHOR "Alex Williamson "
> >> @@ -56,6 +57,7 @@ MODULE_PARM_DESC(disable_hugepages,
> >> struct vfio_iommu {
> >>struct list_headdomain_list;
> >>struct list_headaddr_space_list;
> >> + struct vfio_domain *external_domain; /* domain for external user */
> >>struct mutexlock;
> >>struct rb_root dma_list;
> >>boolv2;
> >> @@ -67,6 +69,9 @@ struct vfio_addr_space {
> >>struct mm_struct*mm;
> >>struct list_headnext;
> >>atomic_tref_count;
> >> + /* external user pinned pfns */
> >> + struct rb_root pfn_list; /* pinned Host pfn list */
> >> + struct mutexpfn_list_lock; /* mutex for pfn_list */
> >> };
> >>
> >> struct vfio_domain {
> >> @@ -83,6 +88,7 @@ struct vfio_dma {
> >>unsigned long vaddr; /* Process virtual addr */
> >>size_t size; /* Map size (bytes) */
> >>int prot; /* IOMMU_READ/WRITE */
> >> + booliommu_mapped;
> >>struct vfio_addr_space *addr_space;
> >>struct task_struct *task;
> >>boolmlock_cap;
> >> @@ -94,6 +100,19 @@ struct vfio_group {
> >> };
> >>
> >> /*
> >> + * Guest RAM pinning working set or DMA target
> >> + */
> >> +struct vfio_pfn {
> >> + struct rb_node node;
> >> + unsigned long pfn;/* Host pfn */
> >> + int prot;
> >> + atomic_tref_count;
> >> +};
> >> +
> >> +#define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) \
> >> + (!list_empty(&iommu->domain_list))
> >> +
> >> +/*
> >> * This code handles mapping and unmapping of user data buffers
> >> * into DMA'ble space using the IOMMU
> >> */
> >> @@ -153,6 +172,93 @@ static struct vfio_addr_space
> >> *vfio_find_addr_space(struct vfio_iommu *iommu,
> >>return NULL;
> >> }
> >>
> >> +/*
> >> + * Helper Functions for host pfn list
> >> + */
> >> +static struct vfio_pfn *vfio_find_pfn(struct vfio_addr_space *addr_space,
> >> +unsigned long pfn)
> >> +{
> >> + struct vfio_pfn *vpfn;
> >> + struct rb_node *node = addr_space->pfn_list.rb_node;
> >> +
> >
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On Tue, 8 Nov 2016 20:36:34 +0530
Kirti Wankhede wrote:
> On 11/8/2016 4:46 AM, Alex Williamson wrote:
> > On Sat, 5 Nov 2016 02:40:44 +0530
> > Kirti Wankhede wrote:
> >
> ...
>
> >> -static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma
> >> *dma)
> >> +static int __vfio_pin_page_external(struct vfio_dma *dma, unsigned long
> >> vaddr,
> >> + int prot, unsigned long *pfn_base,
> >> + bool do_accounting)
> >> +{
> >> + struct task_struct *task = dma->task;
> >> + unsigned long limit = task_rlimit(task, RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> >> + bool lock_cap = dma->mlock_cap;
> >> + struct mm_struct *mm = dma->addr_space->mm;
> >> + int ret;
> >> + bool rsvd;
> >> +
> >> + ret = vaddr_get_pfn(mm, vaddr, prot, pfn_base);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + rsvd = is_invalid_reserved_pfn(*pfn_base);
> >> +
> >> + if (!rsvd && !lock_cap && mm->locked_vm + 1 > limit) {
> >> + put_pfn(*pfn_base, prot);
> >> + pr_warn("%s: Task %s (%d) RLIMIT_MEMLOCK (%ld) exceeded\n",
> >> + __func__, task->comm, task_pid_nr(task),
> >> + limit << PAGE_SHIFT);
> >> + return -ENOMEM;
> >> + }
> >> +
> >> + if (!rsvd && do_accounting)
> >> + vfio_lock_acct(mm, 1);
> >> +
> >> + return 1;
> >> +}
> >> +
> >> +static void __vfio_unpin_page_external(struct vfio_addr_space *addr_space,
> >> + unsigned long pfn, int prot,
> >> + bool do_accounting)
> >> +{
> >> + put_pfn(pfn, prot);
> >> +
> >> + if (do_accounting)
> >> + vfio_lock_acct(addr_space->mm, -1);
> >
> > Can't we batch this like we do elsewhere? Intel folks, AIUI you intend
> > to pin all VM memory through this side channel, have you tested the
> > scalability and performance of this with larger VMs? Our vfio_pfn
> > data structure alone is 40 bytes per pinned page, which means for
> > each 1GB of VM memory, we have 10MBs worth of struct vfio_pfn!
> > Additionally, unmapping each 1GB of VM memory will result in 256k
> > separate vfio_lock_acct() callbacks. I'm concerned that we're not
> > being efficient enough in either space or time.
> >
> > One thought might be whether we really need to save the pfn, we better
> > always get the same result if we pin it again, or maybe we can just do
> > a lookup through the mm at that point without re-pinning. Could we get
> > to the point where we only need an atomic_t ref count per page in a
> > linear array relative to the IOVA?
>
> Ok. Is System RAM hot-plug supported? How is system RAM hot-plug
> handled? Are there DMA_MAP calls on such hot-plug for additional range?
> If we have a linear array/memory, we will have to realloc it on memory
> hot-plug?
I was thinking a linear array for each IOVA page within a vfio_dma.
The array would track the number of references (pins) of each page. It
might actually need to be a page table given that a single vfio_dma can
nearly map the entire 64bit address space. I don't think RAM hotplug
is a factor here, we need to support and properly account for multiple
IOVAs mapping to the same pfn, but the typical case will be a 1:1
mapping, I think that's what we'd optimize for.
> > That would give us 1MB per 1GB
> > overhead. The semantics of the pin and unpin would make more sense then
> > too, both would take an IOVA range, only pinning would need a return
> > mechanism. For instance:
> >
> > int pin_pages(void *iommu_data, dma_addr_t iova_base,
> > int npage, unsigned long *pfn_base);
> >
> > This would pin physically contiguous pages up to npage, returning the
> > base pfn and returning the number of pages pinned (<= npage). The
> > vendor driver would make multiple calls to fill the necessary range.
>
>
> With the current patch, input is user_pfn[] array and npages.
>
> int vfio_pin_pages(struct device *dev, unsigned long *user_pfn,
>int npage, int prot, unsigned long *phys_pfn)
>
>
> When guest allocates memory with malloc(), gfns would not be contiguous,
> right? These gfns (user_pfns) are passed as argument here.
> Is there any case where we could get pin/unpin request for contiguous pages?
It would depend on whether the user within the guest is actually
optimizing for hugepages.
> > Unpin would then simply be:
> >
> > void unpin_pages(void *iommu_data, dma_addr_t iova_base, int npage);
> >
> > Hugepage usage would really make such an interface shine (ie. 2MB+
> > contiguous ranges). A downside would be the overhead of getting the
> > group and container reference in vfio for each callback, perhaps we'd
> > need to figure out how the vendor driver could hold that reference.
>
> In very initial phases of proposal, I had suggested to keep pointer to
> container->iommu_data in struct mdev_device. But that was discarded.
The referencing is definitely tricky, we run into the same p
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On 08/11/16 17:52, Alexey Kardashevskiy wrote: > On 05/11/16 08:10, Kirti Wankhede wrote: >> VFIO IOMMU drivers are designed for the devices which are IOMMU capable. >> Mediated device only uses IOMMU APIs, the underlying hardware can be >> managed by an IOMMU domain. >> >> Aim of this change is: >> - To use most of the code of TYPE1 IOMMU driver for mediated devices >> - To support direct assigned device and mediated device in single module >> >> This change adds pin and unpin support for mediated device to TYPE1 IOMMU >> backend module. More details: >> - vfio_pin_pages() callback here uses task and address space of vfio_dma, >> that is, of the process who mapped that iova range. >> - Added pfn_list tracking logic to address space structure. All pages >> pinned through this interface are trached in its address space. >> - Pinned pages list is used to verify unpinning request and to unpin >> remaining pages while detaching the group for that device. >> - Page accounting is updated to account in its address space where the >> pages are pinned/unpinned. >> - Accouting for mdev device is only done if there is no iommu capable >> domain in the container. When there is a direct device assigned to the >> container and that domain is iommu capable, all pages are already pinned >> during DMA_MAP. >> - Page accouting is updated on hot plug and unplug mdev device and pass >> through device. >> >> Tested by assigning below combinations of devices to a single VM: >> - GPU pass through only > > This does not require this patchset, right? > >> - vGPU device only > > Out of curiosity - how exactly did you test this? The exact GPU, how to > create vGPU, what was the QEMU command line and the guest does with this > passed device? Thanks. ping? -- Alexey
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On 11/15/2016 10:47 AM, Alexey Kardashevskiy wrote: > On 08/11/16 17:52, Alexey Kardashevskiy wrote: >> On 05/11/16 08:10, Kirti Wankhede wrote: >>> VFIO IOMMU drivers are designed for the devices which are IOMMU capable. >>> Mediated device only uses IOMMU APIs, the underlying hardware can be >>> managed by an IOMMU domain. >>> >>> Aim of this change is: >>> - To use most of the code of TYPE1 IOMMU driver for mediated devices >>> - To support direct assigned device and mediated device in single module >>> >>> This change adds pin and unpin support for mediated device to TYPE1 IOMMU >>> backend module. More details: >>> - vfio_pin_pages() callback here uses task and address space of vfio_dma, >>> that is, of the process who mapped that iova range. >>> - Added pfn_list tracking logic to address space structure. All pages >>> pinned through this interface are trached in its address space. >>> - Pinned pages list is used to verify unpinning request and to unpin >>> remaining pages while detaching the group for that device. >>> - Page accounting is updated to account in its address space where the >>> pages are pinned/unpinned. >>> - Accouting for mdev device is only done if there is no iommu capable >>> domain in the container. When there is a direct device assigned to the >>> container and that domain is iommu capable, all pages are already pinned >>> during DMA_MAP. >>> - Page accouting is updated on hot plug and unplug mdev device and pass >>> through device. >>> >>> Tested by assigning below combinations of devices to a single VM: >>> - GPU pass through only >> >> This does not require this patchset, right? >> Sorry I missed this earlier. This testing is required for this patch, because this patch touches code that is used for direct device assignment. Also for page accounting, all cases are considered i.e. when there is only pass through device in a container, when there is pass through device + vGPU device in a container. Also have to test that pages are pinned properly when device is hotplugged. In that case vfio_iommu_replay() is called to take necessary action. >>> - vGPU device only >> >> Out of curiosity - how exactly did you test this? The exact GPU, how to >> create vGPU, what was the QEMU command line and the guest does with this >> passed device? Thanks. > > ping? > I'm testing this code with M60, with custom changes in our driver. Steps how to create mediated device are listed in Documentation/vfio-mediated-device.txt for sample mtty driver. Same steps I'm following for GPU. Quoting those steps here for you: 2. Create a mediated device by using the dummy device that you created in the previous step. # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > \ /sys/devices/virtual/mtty/mtty/mdev_supported_types/mtty-2/create 3. Add parameters to qemu-kvm. -device vfio-pci,\ sysfsdev=/sys/bus/mdev/devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001 Thanks, Kirti
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On 15/11/16 17:33, Kirti Wankhede wrote: > > > On 11/15/2016 10:47 AM, Alexey Kardashevskiy wrote: >> On 08/11/16 17:52, Alexey Kardashevskiy wrote: >>> On 05/11/16 08:10, Kirti Wankhede wrote: VFIO IOMMU drivers are designed for the devices which are IOMMU capable. Mediated device only uses IOMMU APIs, the underlying hardware can be managed by an IOMMU domain. Aim of this change is: - To use most of the code of TYPE1 IOMMU driver for mediated devices - To support direct assigned device and mediated device in single module This change adds pin and unpin support for mediated device to TYPE1 IOMMU backend module. More details: - vfio_pin_pages() callback here uses task and address space of vfio_dma, that is, of the process who mapped that iova range. - Added pfn_list tracking logic to address space structure. All pages pinned through this interface are trached in its address space. - Pinned pages list is used to verify unpinning request and to unpin remaining pages while detaching the group for that device. - Page accounting is updated to account in its address space where the pages are pinned/unpinned. - Accouting for mdev device is only done if there is no iommu capable domain in the container. When there is a direct device assigned to the container and that domain is iommu capable, all pages are already pinned during DMA_MAP. - Page accouting is updated on hot plug and unplug mdev device and pass through device. Tested by assigning below combinations of devices to a single VM: - GPU pass through only >>> >>> This does not require this patchset, right? >>> > > Sorry I missed this earlier. > This testing is required for this patch, because this patch touches code > that is used for direct device assignment. Also for page accounting, all > cases are considered i.e. when there is only pass through device in a > container, when there is pass through device + vGPU device in a > container. Also have to test that pages are pinned properly when device > is hotplugged. In that case vfio_iommu_replay() is called to take > necessary action. So in this particular test you are only testing that the patchset did not break the already existing functionality, is that correct? > - vGPU device only >>> >>> Out of curiosity - how exactly did you test this? The exact GPU, how to >>> create vGPU, what was the QEMU command line and the guest does with this >>> passed device? Thanks. >> >> ping? >> > > I'm testing this code with M60, with custom changes in our driver. Is this shared anywhere? What does the mediated driver do? Can Tesla K80 do the same thing, or [10de:15fe] (whatever its name is)? > Steps how to create mediated device are listed in > Documentation/vfio-mediated-device.txt for sample mtty driver. Same > steps I'm following for GPU. Quoting those steps here for you: Nah, I saw this, I was wondering about actual hardware :) Like when you say "tested with vGPU" - I am wondering what is passed to the guest and how the guest is actually using it. > > 2. Create a mediated device by using the dummy device that you created > in the >previous step. > ># echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > \ > > /sys/devices/virtual/mtty/mtty/mdev_supported_types/mtty-2/create > > 3. Add parameters to qemu-kvm. > >-device vfio-pci,\ > sysfsdev=/sys/bus/mdev/devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001 -- Alexey
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On 11/15/2016 12:57 PM, Alexey Kardashevskiy wrote: > On 15/11/16 17:33, Kirti Wankhede wrote: >> >> >> On 11/15/2016 10:47 AM, Alexey Kardashevskiy wrote: >>> On 08/11/16 17:52, Alexey Kardashevskiy wrote: On 05/11/16 08:10, Kirti Wankhede wrote: > VFIO IOMMU drivers are designed for the devices which are IOMMU capable. > Mediated device only uses IOMMU APIs, the underlying hardware can be > managed by an IOMMU domain. > > Aim of this change is: > - To use most of the code of TYPE1 IOMMU driver for mediated devices > - To support direct assigned device and mediated device in single module > > This change adds pin and unpin support for mediated device to TYPE1 IOMMU > backend module. More details: > - vfio_pin_pages() callback here uses task and address space of vfio_dma, > that is, of the process who mapped that iova range. > - Added pfn_list tracking logic to address space structure. All pages > pinned through this interface are trached in its address space. > - Pinned pages list is used to verify unpinning request and to unpin > remaining pages while detaching the group for that device. > - Page accounting is updated to account in its address space where the > pages are pinned/unpinned. > - Accouting for mdev device is only done if there is no iommu capable > domain in the container. When there is a direct device assigned to the > container and that domain is iommu capable, all pages are already pinned > during DMA_MAP. > - Page accouting is updated on hot plug and unplug mdev device and pass > through device. > > Tested by assigning below combinations of devices to a single VM: > - GPU pass through only This does not require this patchset, right? >> >> Sorry I missed this earlier. >> This testing is required for this patch, because this patch touches code >> that is used for direct device assignment. Also for page accounting, all >> cases are considered i.e. when there is only pass through device in a >> container, when there is pass through device + vGPU device in a >> container. Also have to test that pages are pinned properly when device >> is hotplugged. In that case vfio_iommu_replay() is called to take >> necessary action. > > So in this particular test you are only testing that the patchset did not > break the already existing functionality, is that correct? > > Yes. >> > - vGPU device only Out of curiosity - how exactly did you test this? The exact GPU, how to create vGPU, what was the QEMU command line and the guest does with this passed device? Thanks. >>> >>> ping? >>> >> >> I'm testing this code with M60, with custom changes in our driver. > > > Is this shared anywhere? What does the mediated driver do? Can Tesla K80 do > the same thing, or [10de:15fe] (whatever its name is)? > > No, we are still in the process of upstreaming this patchset. After that we would prepare official drivers. There is no timeline for the driver release yet. >> Steps how to create mediated device are listed in >> Documentation/vfio-mediated-device.txt for sample mtty driver. Same >> steps I'm following for GPU. Quoting those steps here for you: > > > Nah, I saw this, I was wondering about actual hardware :) Like when you say > "tested with vGPU" - I am wondering what is passed to the guest and how the > guest is actually using it. > > Its similar to mtty sample driver, that simulates serial port and so you see serial ports in guest. For vGPU, you see a virtual GPU in guest. Thanks, Kirti >> >> 2. Create a mediated device by using the dummy device that you created >> in the >>previous step. >> >># echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > \ >> >> /sys/devices/virtual/mtty/mtty/mdev_supported_types/mtty-2/create >> >> 3. Add parameters to qemu-kvm. >> >>-device vfio-pci,\ >> sysfsdev=/sys/bus/mdev/devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001 > > > >
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On Sat, 5 Nov 2016 02:40:44 +0530
Kirti Wankhede wrote:
> VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
> Mediated device only uses IOMMU APIs, the underlying hardware can be
> managed by an IOMMU domain.
>
> Aim of this change is:
> - To use most of the code of TYPE1 IOMMU driver for mediated devices
> - To support direct assigned device and mediated device in single module
>
> This change adds pin and unpin support for mediated device to TYPE1 IOMMU
> backend module. More details:
> - vfio_pin_pages() callback here uses task and address space of vfio_dma,
> that is, of the process who mapped that iova range.
> - Added pfn_list tracking logic to address space structure. All pages
> pinned through this interface are trached in its address space.
^ k
--|
> - Pinned pages list is used to verify unpinning request and to unpin
> remaining pages while detaching the group for that device.
> - Page accounting is updated to account in its address space where the
> pages are pinned/unpinned.
> - Accouting for mdev device is only done if there is no iommu capable
> domain in the container. When there is a direct device assigned to the
> container and that domain is iommu capable, all pages are already pinned
> during DMA_MAP.
> - Page accouting is updated on hot plug and unplug mdev device and pass
> through device.
>
> Tested by assigning below combinations of devices to a single VM:
> - GPU pass through only
> - vGPU device only
> - One GPU pass through and one vGPU device
> - Linux VM hot plug and unplug vGPU device while GPU pass through device
> exist
> - Linux VM hot plug and unplug GPU pass through device while vGPU device
> exist
>
> Signed-off-by: Kirti Wankhede
> Signed-off-by: Neo Jia
> Change-Id: I295d6f0f2e0579b8d9882bfd8fd5a4194b97bd9a
> ---
> drivers/vfio/vfio_iommu_type1.c | 538
> +---
> 1 file changed, 500 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 8d64528dcc22..e511073446a0 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #define DRIVER_VERSION "0.2"
> #define DRIVER_AUTHOR "Alex Williamson "
> @@ -56,6 +57,7 @@ MODULE_PARM_DESC(disable_hugepages,
> struct vfio_iommu {
> struct list_headdomain_list;
> struct list_headaddr_space_list;
> + struct vfio_domain *external_domain; /* domain for external user */
> struct mutexlock;
> struct rb_root dma_list;
> boolv2;
> @@ -67,6 +69,9 @@ struct vfio_addr_space {
> struct mm_struct*mm;
> struct list_headnext;
> atomic_tref_count;
> + /* external user pinned pfns */
> + struct rb_root pfn_list; /* pinned Host pfn list */
> + struct mutexpfn_list_lock; /* mutex for pfn_list */
> };
>
> struct vfio_domain {
> @@ -83,6 +88,7 @@ struct vfio_dma {
> unsigned long vaddr; /* Process virtual addr */
> size_t size; /* Map size (bytes) */
> int prot; /* IOMMU_READ/WRITE */
> + booliommu_mapped;
> struct vfio_addr_space *addr_space;
> struct task_struct *task;
> boolmlock_cap;
> @@ -94,6 +100,19 @@ struct vfio_group {
> };
>
> /*
> + * Guest RAM pinning working set or DMA target
> + */
> +struct vfio_pfn {
> + struct rb_node node;
> + unsigned long pfn;/* Host pfn */
> + int prot;
> + atomic_tref_count;
> +};
> +
> +#define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) \
> + (!list_empty(&iommu->domain_list))
> +
> +/*
> * This code handles mapping and unmapping of user data buffers
> * into DMA'ble space using the IOMMU
> */
> @@ -153,6 +172,93 @@ static struct vfio_addr_space
> *vfio_find_addr_space(struct vfio_iommu *iommu,
> return NULL;
> }
>
> +/*
> + * Helper Functions for host pfn list
> + */
> +static struct vfio_pfn *vfio_find_pfn(struct vfio_addr_space *addr_space,
> + unsigned long pfn)
> +{
> + struct vfio_pfn *vpfn;
> + struct rb_node *node = addr_space->pfn_list.rb_node;
> +
> + while (node) {
> + vpfn = rb_entry(node, struct vfio_pfn, node);
> +
> + if (pfn < vpfn->pfn)
> + node = node->rb_left;
> + else if (pfn > vpfn->pfn)
> + node = node->rb_right;
> + else
> + return vpfn;
> + }
> +
> + return NULL;
> +}
> +
> +static void vfio_link_pfn(
Re: [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices
On 11/08/2016 07:16 AM, Alex Williamson wrote:
> On Sat, 5 Nov 2016 02:40:44 +0530
> Kirti Wankhede wrote:
>
>> VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
>> Mediated device only uses IOMMU APIs, the underlying hardware can be
>> managed by an IOMMU domain.
>>
>> Aim of this change is:
>> - To use most of the code of TYPE1 IOMMU driver for mediated devices
>> - To support direct assigned device and mediated device in single module
>>
>> This change adds pin and unpin support for mediated device to TYPE1 IOMMU
>> backend module. More details:
>> - vfio_pin_pages() callback here uses task and address space of vfio_dma,
>> that is, of the process who mapped that iova range.
>> - Added pfn_list tracking logic to address space structure. All pages
>> pinned through this interface are trached in its address space.
> ^ k
> --|
>
>> - Pinned pages list is used to verify unpinning request and to unpin
>> remaining pages while detaching the group for that device.
>> - Page accounting is updated to account in its address space where the
>> pages are pinned/unpinned.
>> - Accouting for mdev device is only done if there is no iommu capable
>> domain in the container. When there is a direct device assigned to the
>> container and that domain is iommu capable, all pages are already pinned
>> during DMA_MAP.
>> - Page accouting is updated on hot plug and unplug mdev device and pass
>> through device.
>>
>> Tested by assigning below combinations of devices to a single VM:
>> - GPU pass through only
>> - vGPU device only
>> - One GPU pass through and one vGPU device
>> - Linux VM hot plug and unplug vGPU device while GPU pass through device
>> exist
>> - Linux VM hot plug and unplug GPU pass through device while vGPU device
>> exist
>>
>> Signed-off-by: Kirti Wankhede
>> Signed-off-by: Neo Jia
>> Change-Id: I295d6f0f2e0579b8d9882bfd8fd5a4194b97bd9a
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 538
>> +---
>> 1 file changed, 500 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c
>> index 8d64528dcc22..e511073446a0 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -36,6 +36,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #define DRIVER_VERSION "0.2"
>> #define DRIVER_AUTHOR "Alex Williamson "
>> @@ -56,6 +57,7 @@ MODULE_PARM_DESC(disable_hugepages,
>> struct vfio_iommu {
>> struct list_headdomain_list;
>> struct list_headaddr_space_list;
>> +struct vfio_domain *external_domain; /* domain for external user */
>> struct mutexlock;
>> struct rb_root dma_list;
>> boolv2;
>> @@ -67,6 +69,9 @@ struct vfio_addr_space {
>> struct mm_struct*mm;
>> struct list_headnext;
>> atomic_tref_count;
>> +/* external user pinned pfns */
>> +struct rb_root pfn_list; /* pinned Host pfn list */
>> +struct mutexpfn_list_lock; /* mutex for pfn_list */
>> };
>>
>> struct vfio_domain {
>> @@ -83,6 +88,7 @@ struct vfio_dma {
>> unsigned long vaddr; /* Process virtual addr */
>> size_t size; /* Map size (bytes) */
>> int prot; /* IOMMU_READ/WRITE */
>> +booliommu_mapped;
>> struct vfio_addr_space *addr_space;
>> struct task_struct *task;
>> boolmlock_cap;
>> @@ -94,6 +100,19 @@ struct vfio_group {
>> };
>>
>> /*
>> + * Guest RAM pinning working set or DMA target
>> + */
>> +struct vfio_pfn {
>> +struct rb_node node;
>> +unsigned long pfn;/* Host pfn */
>> +int prot;
>> +atomic_tref_count;
>> +};
>> +
>> +#define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu) \
>> +(!list_empty(&iommu->domain_list))
>> +
>> +/*
>> * This code handles mapping and unmapping of user data buffers
>> * into DMA'ble space using the IOMMU
>> */
>> @@ -153,6 +172,93 @@ static struct vfio_addr_space
>> *vfio_find_addr_space(struct vfio_iommu *iommu,
>> return NULL;
>> }
>>
>> +/*
>> + * Helper Functions for host pfn list
>> + */
>> +static struct vfio_pfn *vfio_find_pfn(struct vfio_addr_space *addr_space,
>> + unsigned long pfn)
>> +{
>> +struct vfio_pfn *vpfn;
>> +struct rb_node *node = addr_space->pfn_list.rb_node;
>> +
>> +while (node) {
>> +vpfn = rb_entry(node, struct vfio_pfn, node);
>> +
>> +if (pfn < vpfn->pfn)
>> +node = node->rb_left;
>> +else if (pfn > vpfn->pfn)
>> +node = nod
