On Fri, 27 Jul 2018 12:59:50 +0200 Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > On 07/27/2018 10:38 AM, Cornelia Huck wrote: > > On Thu, 26 Jul 2018 21:54:07 +0200 > > Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > > > >> * The mediated device gained an 'activate' attribute. Sharing conflicts are > >> checked on activation now. If the device was not activated, the mdev > >> open still implies activation. An active ap_matrix_mdev device claims > >> it's resources -- an inactive does not. > > > > This means we have a 'commit' workflow? > > Yes. We want to be able to "overcommit" definitions. For example when you > have 2 guests that you never start at the same time. Then you can give both > guests the same disks. If you start at the same time, libvirt will complain. > Now: you want to do the same for matrixes. Allocation at definition time > would limit that flexibility. When we check at "commit" this allows overcommit. I raised an eyebrow to this 'activate' attribute as well and I think we struggled through the same sort of thing when defining mdev initially with NVIDIA. IIRC there was a proposal that mdev devices could effectively be overcommitted on the parent and only when they were opened, would the allocation count against the available instances. The trouble is then that libvirt has no guarantee that a given mdev device is usable. I believe we decided that the creation of the mdev device is the point at which we want to reserve resources because it provides a better synchronization point. I don't really see what advantage we have by having these matrices on 'standby', shouldn't userspace be able to manipulate these dynamically and on-demand of starting a VM? Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
