[lkml]   [2020]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 03/15] s390/zcrypt: driver callback to indicate resource in use

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.


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

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.


Pierre Morel
IBM Lab Boeblingen

 \ /
  Last update: 2020-04-28 10:09    [W:0.067 / U:2.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site