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.)
Yes, exactly that is what we tried to describe in the limitations section.
The sysfs update and ap_owned_by_def_drv() both take ap_rights_mutex
so it's kind of race free (see #6). But the lock not held during the
whole resorting. So I would not say it is completely race free. But
at least vfio_ap won't observe inconsistent state and things will
eventually settle.
Who is supposed to manage the reserved masks? libvirt in conjunction
with managing the vfio-ap matrix?
AFAIU the reserved masks should be a pretty stable thing. The idea is that
the admin decides what resources are for zcrypt usage and what resources
for vfio-ap. Then the admin either sets the kernel command line parameters
accordingly, or makes it so that the masks get changed during the init
process.
* 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?
I think it can be put like that.
* 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...)
We may want to provide a more machine friendly interface later. The error reporting
via sysfs is kind of difficult, and having the guest matrix set (or rejected) in one
atomic operation without having to first build state (series of assign operations)
and then commit it is preferred by our management software (libvirt) people.
BTW there is a comment about that in the code.
* 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?
The retry count was reduced from 50 to 2. Basically if the ZAPQ fails:
* there ain't much we can do
* the architecture guarantees that we are kind of good (RAPQ good)
anyway
Regards,
Halil
--
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
--
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
