Re: [PATCH v7 00/22] vfio-ap: guest dedicated crypto adapters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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?
> 




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux