[lkml]   [2018]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v5 06/13] KVM: s390: interfaces to manage guest's AP matrix
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.

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

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

 \ /
  Last update: 2018-05-18 10:56    [W:0.283 / U:0.008 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site