On 8/10/2016 12:30 AM, Alex Williamson wrote: > On Thu, 4 Aug 2016 00:33:51 +0530 > Kirti Wankhede <kwankhede@xxxxxxxxxx> wrote: > > This is used later by mdev_device_start() and mdev_device_stop() to get > the parent_device so it can call the start and stop ops callbacks > respectively. That seems to imply that all of instances for a given > uuid come from the same parent_device. Where is that enforced? I'm > still having a hard time buying into the uuid+instance plan when it > seems like each mdev_device should have an actual unique uuid. > Userspace tools can figure out which uuids to start for a given user, I > don't see much value in collecting them to instances within a uuid. > Initially we started discussion with VM_UUID+instance suggestion, where instance was introduced to support multiple devices in a VM. 'mdev_create' creates device and 'mdev_start' is to commit resources of all instances of similar devices assigned to VM. For example, to create 2 devices: # echo "$UUID:0:params" > /sys/devices/../mdev_create # echo "$UUID:1:params" > /sys/devices/../mdev_create "$UUID-0" and "$UUID-1" devices are created. Commit resources for above devices with single 'mdev_start': # echo "$UUID" > /sys/class/mdev/mdev_start Considering $UUID to be a unique UUID of a device, we don't need 'instance', so 'mdev_create' would look like: # echo "$UUID1:params" > /sys/devices/../mdev_create # echo "$UUID2:params" > /sys/devices/../mdev_create where $UUID1 and $UUID2 would be mdev device's unique UUID and 'params' would be vendor specific parameters. Device nodes would be created as "$UUID1" and "$UUID" Then 'mdev_start' would be: # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_start Similarly 'mdev_stop' and 'mdev_destroy' would be: # echo "$UUID1, $UUID2" > /sys/class/mdev/mdev_stop and # echo "$UUID1" > /sys/devices/../mdev_destroy # echo "$UUID2" > /sys/devices/../mdev_destroy Does this seems reasonable? Thanks, Kirti -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
