qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration


From: Tian, Kevin
Subject: Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration
Date: Tue, 20 Sep 2016 01:37:37 +0000

> From: Kirti Wankhede [mailto:address@hidden
> Sent: Tuesday, September 20, 2016 4:36 AM
> 
> 
> Hi libvirt experts,
> 
> Thanks for valuable input on v1 version of RFC.
> 
> Quick brief, VFIO based mediated device framework provides a way to
> virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT
> and IBM's channel IO. This framework reuses VFIO APIs for all the
> functionalities for mediated devices which are currently being used for
> pass through devices. This framework introduces a set of new sysfs files
> for device creation and its life cycle management.
> 
> Here is the summary of discussion on v1:
> 1. Discover mediated device:
> As part of physical device initialization process, vendor driver will
> register their physical devices, which will be used to create virtual
> device (mediated device, aka mdev) to the mediated framework.
> 
> Vendor driver should specify mdev_supported_types in directory format.
> This format is class based, for example, display class directory format
> should be as below. We need to define such set for each class of devices
> which would be supported by mediated device framework.
> 
>  --- mdev_destroy
>  --- mdev_supported_types
>      |-- 11
>      |   |-- create
>      |   |-- name
>      |   |-- fb_length
>      |   |-- resolution
>      |   |-- heads
>      |   |-- max_instances
>      |   |-- params
>      |   |-- requires_group
>      |-- 12
>      |   |-- create
>      |   |-- name
>      |   |-- fb_length
>      |   |-- resolution
>      |   |-- heads
>      |   |-- max_instances
>      |   |-- params
>      |   |-- requires_group
>      |-- 13
>          |-- create
>          |-- name
>          |-- fb_length
>          |-- resolution
>          |-- heads
>          |-- max_instances
>          |-- params
>          |-- requires_group
> 
> 

Per previous discussion, I'd think below layout is more general and clearer:

  --- mdev_supported_types
      |-- ID (or name)
      |   |-- create
      |   |-- available_instances
      |   |-- requires_group
      |-- ID (or name)
      |   |-- create
      |   |-- available_instances
      |   |-- requires_group
         ...

Then under each mdev directory:
      |-- type (link to type directory)
      |-- destroy
      |-- online
      |-- reset
      |-- Destroy

Group association may be done under mdev directory too, per Alex's earlier
suggestion.

Optional vendor-agnostic attributes can be extended in the future, e.g.:
      |-- priority
      |-- weight

Vendor-specific or class-specific parameters (black string or explicit 
attributes) 
could be also extended per-mdev directory, if necessary to support.

Thanks
Kevin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]