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.) Who is supposed to manage the reserved masks? libvirt in conjunction with managing the vfio-ap matrix? > * 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? > * 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
