From: Alex Williamson <alex.williamson@redhat.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: libvir-list@redhat.com, intel-gvt-dev@lists.freedesktop.org,
cjia@nvidia.com, kvm@vger.kernel.org, eskultet@redhat.com
Subject: Re: [libvirt] [PATCH v2 1/1] Add attribute single_usage_restriction for mdev type-id
Date: Wed, 10 Oct 2018 14:38:47 -0600 [thread overview]
Message-ID: <20181010143847.61c221d3@w520.home> (raw)
In-Reply-To: <1539029417-19371-1-git-send-email-kwankhede@nvidia.com>
On Tue, 9 Oct 2018 01:40:17 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> Generally a single instance of mdev device, a share of physical device, is
> assigned to user space application or a VM. There are cases when multiple
> instances of mdev devices of same or different types are required by user
> space application or VM. For example in case of vGPU, multiple mdev devices
> of type which represents whole GPU can be assigned to one instance of
> application or VM.
>
> All types of mdev devices may not support assigning multiple mdev devices
> to a user space application. In that case vendor driver can fail open()
> call of mdev device. But there is no way to know User space application to
> about the configuration supported by vendor driver.
>
> To expose supported configuration, vendor driver should add
> 'single_usage_restriction' attribute to type-id directory. Returning Y for
> this attribute indicates vendor driver has restriction of single mdev
> device of particular <type-id> assigned to one user space application.
> Returning N indicates that multiple mdev devices of particular <type-id>
> can be assigned to one user space application.
>
> User space application should read if 'single_usage_restriction' attibute
> is present in <type-id> directory of all mdev devices which are going to be
> used. If all read N then user space application can proceed with multiple
> mdev devices.
>
> This is optional and readonly attribute.
>
> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
> Reviewed-by: Neo Jia <cjia@nvidia.com>
> ---
> Documentation/ABI/testing/sysfs-bus-vfio-mdev | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-vfio-mdev b/Documentation/ABI/testing/sysfs-bus-vfio-mdev
> index 452dbe39270e..3aca352a70e5 100644
> --- a/Documentation/ABI/testing/sysfs-bus-vfio-mdev
> +++ b/Documentation/ABI/testing/sysfs-bus-vfio-mdev
> @@ -85,6 +85,22 @@ Users:
> a particular <type-id> that can help in understanding the
> features provided by that type of mediated device.
>
> +What: /sys/.../mdev_supported_types/<type-id>/single_usage_restriction
> +Date: October 2018
> +Contact: Kirti Wankhede <kwankhede@nvidia.com>
> +Description:
> + Reading this attribute will return Y or N. Returning Y indicates
> + vendor driver has restriction of single mdev device of this
> + particular <type-id> assigned to one user space application.
> + Returning N indicates that multiple mdev devices of particular
> + <type-id> can be assigned to one user space application.
> + This is optional and readonly attribute.
> +Users:
> + User space application should read if 'single_usage_restriction'
> + attibute is present in <type-id> directory of all mdev devices
> + which are going to be used. If all read N then user space
> + application can proceed with multiple mdev devices.
But we don't say what userspace should do when this optional attribute
is not present. Do we know of any cases other than the NVIDIA GRID
vGPU drivers that have this restriction? Intel folks, are multiple
GVT-g mdevs currently allowed in a VM? I don't think the libvirt
algorithm is going to be as simple as suggested here and we should
probably understand what it really needs to be.
There's also a scope issue that's unclear here, the verbiage above
suggests that I can't combine a 'single_usage_restriction=Y' mdev with
any other mdev, but clearly there's no dependency between adding both
an NVIDIA and Intel vGPU to the same VM, right? Or NVIDIA and any of
the mdev sample drivers. The restriction is across mdev types and
parent devices in this case, but I think it stops at the vendor driver,
right? How do we make that more clear, both in wording and perhaps
implicit in the attribute itself? Thanks,
Alex
next prev parent reply other threads:[~2018-10-10 20:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-08 20:10 [libvirt] [PATCH v2 1/1] Add attribute single_usage_restriction for mdev type-id Kirti Wankhede
2018-10-10 20:38 ` Alex Williamson [this message]
2018-10-10 23:22 ` Tian, Kevin
2018-10-11 1:14 ` Zhenyu Wang
2018-10-11 2:08 ` Alex Williamson
2018-10-17 9:05 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181010143847.61c221d3@w520.home \
--to=alex.williamson@redhat.com \
--cc=cjia@nvidia.com \
--cc=eskultet@redhat.com \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=libvir-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox