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

[Pierre Morel <pmorel@linux.ibm.com>]

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