On 07/27/2018 10:38 AM, Cornelia Huck wrote: > On Thu, 26 Jul 2018 21:54:07 +0200 > Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > > >> v6 => v7 Change log: >> =================== >> * The AP bus gained the ability to designate queues as 'used by host' >> or as 'used by alternate driver(s)'. This allows us to authorise access >> (via the CRYCB) to queues that are not currently bound to the vfio_ap >> driver. If a vfio_ap owned queue diss- and reapears it's guaranteed >> to get bound back to the vfio_ap driver. > > Hm... how does this interact with the ability to modify the reserved > masks via sysfs? (I have taken only a quick look at that patch, and I'm > not 100% confident that this is race-free; I'll need to think about it > some more.) If the reserved masks can be changed dynamically, this kind > of voids the guarantee, doesn't it? (Although that probably is a > shoot-yourself-in-the-foot case.) The whole scheme would actually work without these two patches if the host has stable devices. We added this as an additional safety net in a sense that it allows to guarantee that everything is proper when used correctly. For example "flickering devices -e.g. due to firmware update" that go away and come back in the host would otherwise cause problems. (and even worse solution would be to forbid usage on zcrypt in the host) If you want to shoot yourself in the foot you could in the previous version unbind/rebind in the host. So the sysfs interfaces always allowed to shoot-yourself in the foot. The alternative would be to not allow to change the mask via sysfs: here the result would be that you need a reboot if the admin wants to revert something back. I think giving the admin the power to apply changes is the better way - even if "root" must know what it is doing. > > Who is supposed to manage the reserved masks? libvirt in conjunction > with managing the vfio-ap matrix? the mask is more like: reserve these things for the host, everything else is for guests. So the assignment for the host is now similar to its guest. You can define a matrix for the host, instead of the host choosing randomly or picking the remainder. This will also help with host hotplug in the future. So in essence this is a host admin property. We will likely provide tooling in chzcrypt,lszcrypt,chzdev to make this more user friendly in the future. So it is not libvirt. > >> * 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. > >> * An active ap_matrix_mdev device can not be removed. An ap_matrix_mdev >> that is hooked up with a guest can not be deactivated. >> * An active ap_matrix_mdev device rejects assign_* and deassign_* >> operations. Thus changing the CRYCB masks of a guest in order to >> accomplys certain hotplug scenarios is planned, but not supported yet. In >> previous versions it was possible to do those operations on a ap_matrix_mdev >> that is hooked up to a guest, but the changes would take effect on the next >> mdev_open. >> * Synchronisation was reworked. >> * The sysfs path of the parent device changed from /sys/devices/vfio_ap/matrix/ >> to /sys/devices/virtual/misc/vfio_ap/. The parent device is a misc >> device now. > > Any particular reason for that change? (Not that I object to misc > devices...) > >> * The severity for most of the messages were reduced form error to >> warning. >> * We are not as thick headed about the zapq as we used to be in v6. > > Hm? > -- 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
