Re: [PATCH v7 03/15] s390/zcrypt: driver callback to indicate resource in use

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

 





On 2020-04-28 00:24, Tony Krowiak wrote:


On 4/27/20 4:20 AM, Pierre Morel wrote:


On 2020-04-07 21:20, Tony Krowiak wrote:
Introduces a new driver callback to prevent a root user from unbinding
an AP queue from its device driver if the queue is in use. The intent of
this callback is to provide a driver with the means to prevent a root user
from inadvertently taking a queue away from a guest and giving it to the
host while the guest is still using it.

...snip...


This functionality is valid for the host as for the guests and is handled automatically by the firmware with the CRYCB. The AP bus uses QCI to retrieve the host CRYCB and build the hosts AP queues.

If instead to mix VFIO CRYCB matrix handling and queues at the same level inside the AP bus we separate these different firmware entities in two different software entities.

If we make the AP bus sit above a CRYCB/Matrix bus, and in the way virtualize the QCI and test AP queue instructions: - we can directly pass a matrix device to the guest though a VFIO matrix device
- the consistence will be automatic
- the VFIO device and parent device will be of the same kind which would make the design much more clearer. - there will be no need for these callback because the consistence of the matrix will be guaranteed by firmware

As stated in my response above, the issue here is not consistency. While the design you describe may be reasonable, it is a major departure from what is out in the field. In other words, that ship
has sailed.


The current VFIO-AP driver works as before, without any change, above the Matrix device I suggest.

Aside the old scheme which can continue, the Matrix device can be used directly to build a VFIO Matrix device, usable by QEMU without any modification.

Once the dynamic extensions proposed in this series and the associated tools are out on the field, then yes the ship is really far. For now, the existing user's API do not change, the existing tools do not need modifications and we can repair the ship for its long journey.

The inconsistency between device and VFIO device and the resulting complexity is not going to ease future enhancement.

Regards,
Pierre



--
Pierre Morel
IBM Lab Boeblingen



[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