kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhenyu Wang <zhenyuw@linux.intel.com>
To: Alex Williamson <alex.williamson@redhat.com>,
	"Tian, Kevin" <kevin.tian@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>,
	kvm@vger.kernel.org, kwankhede@nvidia.com, kevin.tian@intel.com,
	cohuck@redhat.com, Libvirt Devel <libvir-list@redhat.com>,
	Pavel Hrdina <phrdina@redhat.com>,
	Jonathon Jongsma <jjongsma@redhat.com>
Subject: Re: [PATCH 0/6] VFIO mdev aggregated resources handling
Date: Wed, 6 Nov 2019 12:20:31 +0800	[thread overview]
Message-ID: <20191106042031.GJ1769@zhen-hp.sh.intel.com> (raw)
In-Reply-To: <20191105141042.17dd2d7d@x1.home>

[-- Attachment #1: Type: text/plain, Size: 5612 bytes --]

On 2019.11.05 14:10:42 -0700, Alex Williamson wrote:
> On Thu, 24 Oct 2019 13:08:23 +0800
> Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
> 
> > Hi,
> > 
> > This is a refresh for previous send of this series. I got impression that
> > some SIOV drivers would still deploy their own create and config method so
> > stopped effort on this. But seems this would still be useful for some other
> > SIOV driver which may simply want capability to aggregate resources. So here's
> > refreshed series.
> > 
> > Current mdev device create interface depends on fixed mdev type, which get uuid
> > from user to create instance of mdev device. If user wants to use customized
> > number of resource for mdev device, then only can create new mdev type for that
> > which may not be flexible. This requirement comes not only from to be able to
> > allocate flexible resources for KVMGT, but also from Intel scalable IO
> > virtualization which would use vfio/mdev to be able to allocate arbitrary
> > resources on mdev instance. More info on [1] [2] [3].
> > 
> > To allow to create user defined resources for mdev, it trys to extend mdev
> > create interface by adding new "aggregate=xxx" parameter following UUID, for
> > target mdev type if aggregation is supported, it can create new mdev device
> > which contains resources combined by number of instances, e.g
> > 
> >     echo "<uuid>,aggregate=10" > create
> > 
> > VM manager e.g libvirt can check mdev type with "aggregation" attribute which
> > can support this setting. If no "aggregation" attribute found for mdev type,
> > previous behavior is still kept for one instance allocation. And new sysfs
> > attribute "aggregated_instances" is created for each mdev device to show allocated number.
> 
> Given discussions we've had recently around libvirt interacting with
> mdev, I think that libvirt would rather have an abstract interface via
> mdevctl[1].  Therefore can you evaluate how mdevctl would support this
> creation extension?  It seems like it would fit within the existing
> mdev and mdevctl framework if aggregation were simply a sysfs attribute
> for the device.  For example, the mdevctl steps might look like this:
> 
> mdevctl define -u UUID -p PARENT -t TYPE
> mdevctl modify -u UUID --addattr=mdev/aggregation --value=2
> mdevctl start -u UUID
> 
> When mdevctl starts the mdev, it will first create it using the
> existing mechanism, then apply aggregation attribute, which can consume
> the necessary additional instances from the parent device, or return an
> error, which would unwind and return a failure code to the caller
> (libvirt).  I think the vendor driver would then have freedom to decide
> when the attribute could be modified, for instance it would be entirely
> reasonable to return -EBUSY if the user attempts to modify the
> attribute while the mdev device is in-use.  Effectively aggregation
> simply becomes a standardized attribute with common meaning.  Thoughts?
> [cc libvirt folks for their impression] Thanks,

I think one problem is that before mdevctl start to create mdev you
don't know what vendor attributes are, as we apply mdev attributes
after create. You may need some lookup depending on parent.. I think
making aggregation like other vendor attribute for mdev might be the
simplest way, but do we want to define its behavior in formal? e.g
like previous discussed it should show maxium instances for aggregation, etc.

The behavior change for driver is that previously aggregation is
handled at create time, but for sysfs attr it should handle any
resource allocation before it's really in-use. I think some SIOV
driver which already requires some specific config should be ok,
but not sure for other driver which might not be explored in this before.
Would that be a problem? Kevin?

Thanks

> 
> Alex
> 
> [1] https://github.com/mdevctl/mdevctl
> 
> > References:
> > [1] https://software.intel.com/en-us/download/intel-virtualization-technology-for-directed-io-architecture-specification
> > [2] https://software.intel.com/en-us/download/intel-scalable-io-virtualization-technical-specification
> > [3] https://schd.ws/hosted_files/lc32018/00/LC3-SIOV-final.pdf
> > 
> > Zhenyu Wang (6):
> >   vfio/mdev: Add new "aggregate" parameter for mdev create
> >   vfio/mdev: Add "aggregation" attribute for supported mdev type
> >   vfio/mdev: Add "aggregated_instances" attribute for supported mdev
> >     device
> >   Documentation/driver-api/vfio-mediated-device.rst: Update for
> >     vfio/mdev aggregation support
> >   Documentation/ABI/testing/sysfs-bus-vfio-mdev: Update for vfio/mdev
> >     aggregation support
> >   drm/i915/gvt: Add new type with aggregation support
> > 
> >  Documentation/ABI/testing/sysfs-bus-vfio-mdev | 24 ++++++
> >  .../driver-api/vfio-mediated-device.rst       | 23 ++++++
> >  drivers/gpu/drm/i915/gvt/gvt.c                |  4 +-
> >  drivers/gpu/drm/i915/gvt/gvt.h                | 11 ++-
> >  drivers/gpu/drm/i915/gvt/kvmgt.c              | 53 ++++++++++++-
> >  drivers/gpu/drm/i915/gvt/vgpu.c               | 56 ++++++++++++-
> >  drivers/vfio/mdev/mdev_core.c                 | 36 ++++++++-
> >  drivers/vfio/mdev/mdev_private.h              |  6 +-
> >  drivers/vfio/mdev/mdev_sysfs.c                | 79 ++++++++++++++++++-
> >  include/linux/mdev.h                          | 19 +++++
> >  10 files changed, 294 insertions(+), 17 deletions(-)
> > 
> 

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  reply	other threads:[~2019-11-06  4:20 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24  5:08 [PATCH 0/6] VFIO mdev aggregated resources handling Zhenyu Wang
2019-10-24  5:08 ` [PATCH 1/6] vfio/mdev: Add new "aggregate" parameter for mdev create Zhenyu Wang
2019-10-24  5:08 ` [PATCH 2/6] vfio/mdev: Add "aggregation" attribute for supported mdev type Zhenyu Wang
2019-10-27  6:24   ` kbuild test robot
2019-10-27  6:24   ` [RFC PATCH] vfio/mdev: mdev_type_attr_aggregation can be static kbuild test robot
2019-10-24  5:08 ` [PATCH 3/6] vfio/mdev: Add "aggregated_instances" attribute for supported mdev device Zhenyu Wang
2019-10-24  5:08 ` [PATCH 4/6] Documentation/driver-api/vfio-mediated-device.rst: Update for vfio/mdev aggregation support Zhenyu Wang
2019-10-24  5:08 ` [PATCH 5/6] Documentation/ABI/testing/sysfs-bus-vfio-mdev: " Zhenyu Wang
2019-10-24  5:08 ` [PATCH 6/6] drm/i915/gvt: Add new type with " Zhenyu Wang
2019-11-05 21:10 ` [PATCH 0/6] VFIO mdev aggregated resources handling Alex Williamson
2019-11-06  4:20   ` Zhenyu Wang [this message]
2019-11-06 18:44     ` Alex Williamson
2019-11-07 13:02       ` Cornelia Huck
2019-11-15  4:24       ` Tian, Kevin
2019-11-19 22:58         ` Alex Williamson
2019-11-20  0:46           ` Tian, Kevin
2019-11-07 20:37 ` Parav Pandit
2019-11-08  8:19   ` Zhenyu Wang
2019-12-04 17:36     ` Parav Pandit
2019-12-05  6:06       ` Zhenyu Wang
2019-12-05  6:40         ` Jason Wang
2019-12-05 19:02           ` Parav Pandit
2019-12-05 18:59         ` Parav Pandit
2019-12-06  8:03           ` Zhenyu Wang
2019-12-06 17:33             ` Parav Pandit
2019-12-10  3:33               ` Tian, Kevin
2019-12-10 19:07                 ` Alex Williamson
2019-12-10 21:08                   ` Parav Pandit
2019-12-10 22:08                     ` Alex Williamson
2019-12-10 22:40                       ` Parav Pandit

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=20191106042031.GJ1769@zhen-hp.sh.intel.com \
    --to=zhenyuw@linux.intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=jjongsma@redhat.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=libvir-list@redhat.com \
    --cc=phrdina@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;
as well as URLs for NNTP newsgroup(s).