8:25 p.m.
From: Alex Williamson [mailto:alex.williamson@redhat.com]
Sent: Tuesday, September 20, 2016 5:36 AM
> In the above example directory '11' represents a type id of mdev device.
> 'name', 'fb_length', 'resolution', 'heads',
'max_instance' and
> 'requires_group' would be Read-Only files that vendor would provide to
> describe about that type.
>
> 'create':
> Write-only file. Mandatory.
> Accepts string to create mediated device.
>
> 'name':
> Read-Only file. Mandatory.
> Returns string, the name of that type id.
>
> 'fb_length':
> Read-only file. Mandatory.
> Returns <number>{K,M,G}, size of framebuffer.
This can't be mandatory, it's only relevant to vGPU devices, vGPUs are
just one user of mediated devices.
Agree. at least it doesn't make sense for s390 passthrough usage.
>
> 'max_instance':
> Read-Only file. Mandatory.
> Returns integer. Returns maximum mdev device could be created
> at the moment when this file is read. This count would be updated by
> vendor driver. Before creating mdev device of this type, check if
> max_instance is > 0.
Didn't we discuss this being being something like "available_instances"
with a "devices" sub-directory linking current devices of that type?
Right. "available_instances" which is dynamically changed under two scenarios:
a) create a new mdev under one type decrements "available_instances" of this
type by 1;
b) create a new mdev under one type decrements "available_instances" under
other types by type-specific number, if vendor supports creating multiple types
simultaneously like in Intel solution;
> 'params'
> Write-Only file. Optional.
> String input. Libvirt would pass the string given in XML file to
> this file and then create mdev device. Set empty string to clear params.
> For example, set parameter 'frame_rate_limiter=0' to disable frame rate
> limiter for performance benchmarking, then create device of type 11. The
> device created would have that parameter set by vendor driver.
Might as well just call it "magic", there's absolutely no ability to
introspect what parameters are allowed or even valid here. Can all
parameters be changed dynamically? Do parameter changes apply to
existing devices or only future devices? This is a poorly specified
interface. I'd prefer this be done via module options on the vendor
driver.
I guess it might be mdev specific for nvidia's case, then module option
is not suitable. Then this magic string should be placed under mdev
directory instead of here, otherwise there'll be race condition.
>
> 2. Create/destroy mediated device
>
> With above example, vGPU device XML would look like:
>
> <device>
> <name>my-vgpu</name>
> <parent>pci_0000_86_00_0</parent>
> <capability type='mdev'>
> <type id='11'/>
> <group>1</group>
> <params>'frame_rate_limiter=0'</params>
> </capability>
> </device>
>
> 'type id' is mandatory.
I was under the impression that the vendor supplied "name" was the one
unique identifier. We're certainly not going to create a registrar to
hand out type ids to each vendor, so what makes type id unique? I have
a hard time believing that a given vendor can even allocate unique type
ids for their own devices. Unique type id across vendors is not
practical. So which attribute are we actually using to identify which
type of mdev device we need and why would we ever specify additional
attributes like fb_length? Doesn't the vendor guarantee that "GRID
M60-0B" has a fixed setup of those attributes?
I'm a bit confused about type ID and type name here. Just keeping one
should be enough (ether a number or descriptive name), which is
per-device scope, not necessarily to cross vendors. As long as the vendor
defines the ID or name unique cross its own generations, looks should be
sufficient (I guess cross-vendor migration is not an interest here)
> 'params' is optional field. User should set this field if extra
> parameters need to be set for a particular vGPU device. Libvirt don't
> need to parse these params. These are meant for vendor driver.
ie. magic black hole. nope.
A curious question here, though it's not a mandatory requirement for
Intel's GPU virtualization solution now, but allow such extension might
be useful in the long term. Has libvirt ever supported similar black
string in other usages? I can think it's a problem for public cloud usage,
where any configuration on the managed device should be controlled
by orchestration layer (e.g. openstack) automatically. It's not appropriate
to allow a cloud tenant specifying such parameter, so in that manner
any configuration parameter should be explicitly understood from upper
level stack to libvirt then vendor specific parameters would be hard to
handle. On the other hand, if we consider enterprise virtualization
scenario which is more proprietary, administrator may add such vendor
specific parameters as a black string through libvirt, as long as he
knows the underlying capability on purchased devices. Then is the latter
a valid value to consider such extension? :-)
Thanks
Kevin