Re: [PATCH v5 06/13] KVM: s390: interfaces to manage guest's AP matrix

Pierre Morel
2018-05-24T07:46:58Z

On 23/05/2018 16:29, Tony Krowiak wrote:
> On 05/18/2018 04:55 AM, Pierre Morel wrote:
>> On 16/05/2018 15:48, Tony Krowiak wrote:
>>> On 05/16/2018 09:15 AM, Pierre Morel wrote:
>>>> On 16/05/2018 15:12, Tony Krowiak wrote:
>>>>> On 05/16/2018 03:48 AM, Pierre Morel wrote:
>>>>>> On 15/05/2018 18:07, Tony Krowiak wrote:
>>>>>>> On 05/15/2018 10:55 AM, Pierre Morel wrote:
>>>>>>>> On 07/05/2018 17:11, Tony Krowiak wrote:
>>>>>>>>> Provides interfaces to manage the AP adapters, usage domains
>>>>>>>>> and control domains assigned to a KVM guest.
>>>>>>>>>
>>>>>>>>> The guest's SIE state description has a satellite structure
>>>>>>>>> called the
>>>>>>>>> Crypto Control Block (CRYCB) containing three bitmask fields
>>>>>>>>> identifying the adapters, queues (domains) and control domains
>>>>>>>>> assigned to the KVM guest:
>>>>>>>>>
>>>>>> ...snip...
>>>>>>>>> +}
>>>>>>>>
>>>>>>>> This function (ap_validate_queue_sharing) only verifies that VM
>>>>>>>> don't share queues.
>>>>>>>> What about the queues used by a host application?
>>>>>>>
>>>>>>> How can that be verified from this function? I suppose I could
>>>>>>> put a check in here to
>>>>>>> verify that the queues are reserved by the vfio_ap device
>>>>>>> driver, but that would
>>>>>>> be redundant because an AP queue can not be assigned to a
>>>>>>> mediated matrix device
>>>>>>> via its sysfs attributes unless it is reserved by the vfio_ap
>>>>>>> device driver (see
>>>>>>> patches 7, 8 and 9).
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I understand that you want to implement  these checks within
>>>>>>>> KVM but this is
>>>>>>>> related to which queue devices are bound to the matrix and
>>>>>>>> which one are not.
>>>>>>>
>>>>>>> See my comments above and below about AP queue assignment to the
>>>>>>> mediated matrix
>>>>>>> device. The one verification we can't do when the devices are
>>>>>>> assigned is whether
>>>>>>> another guest is using the queue because assignment occurs
>>>>>>> before the guest using
>>>>>>> the queue is started in which case we have no access to KVM. It
>>>>>>> makes no sense to
>>>>>>> do so at assignment time anyway because it doesn't matter until
>>>>>>> the guest using
>>>>>>> the mediated matrix device is started, so that check is done in
>>>>>>> KVM.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I think that this should be related somehow to the bounded
>>>>>>>> queue devices and
>>>>>>>> therefor implemented inside the matrix driver.
>>>>>>>
>>>>>>> As I stated above, when an AP queue is assigned to the mediated
>>>>>>> matrix device via
>>>>>>> its sysfs attributes, a check is done to verify that it is bound
>>>>>>> to the vfio_ap
>>>>>>> device driver (see patches 7, 8 and 9). If not, then assignment
>>>>>>> will be rejected;
>>>>>>> therefore, it will not be possible to configure a CRYCB with AP
>>>>>>> queues that are
>>>>>>> not bound to the device driver.
>>>>>>
>>>>>> This patch and te followed patches take care that the queues are
>>>>>> bound to the
>>>>>> matrix driver when they are assigned to the matrix using the
>>>>>> sysfs entries.
>>>>>>
>>>>>> But they do not take care that the queue can not be unbound
>>>>>> before you start
>>>>>> the guest, and they are not in the path if the admin decide to
>>>>>> unbind a queue
>>>>>> at some later time.
>>>>>
>>>>> That is a good point. I need to put a check in the device driver
>>>>> at the time
>>>>> the mediated device fd is opened to verify that the queues being
>>>>> configured in
>>>>> the guest's CRYCB are bound to the driver.
>>>>
>>>> not only, you also need to avoid the possibility of unbinding the
>>>> device.
>>>> For this you need to use the remove callback from the driver.
>>>
>>> I thought I addressed this already. The definition of the remove
>>> callback does
>>> not specify a return value, so there is currently no way to prevent
>>> the AP bus
>>> from removing the queue device on unbind. I sent an email to Harald
>>> to discuss
>>> adding a return value to the callback.
>>
>> If you can not prevent the unbinding you must remove
>> the according bits in the matrix.
>
> In which matrix? The bits in the matrix configured via the mediated
> matrix device's
> sysfs attributes files? The bits in the guest's CRYCB? If the latter,
> then what happens
> to in-process crypto transactions on the guest? Wouldn't this
> essentially be like a hot
> unplug of the device from the guest?

Obviously from the CRYCB so that the guest do not access to the AP queues
belonging to the AP card anymore.

>
>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Pierre
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany