Re: [qemu-s390x] [PATCH RFC] vfio-ap: flag as compatible with balloon

[David Hildenbrand]

On 05.12.18 18:25, Christian Borntraeger wrote:
> 
> 
> On 05.12.2018 17:45, Cornelia Huck wrote:
>> On Wed, 5 Dec 2018 17:38:22 +0100
>> David Hildenbrand <address@hidden> wrote:
>>
>>> On 05.12.18 15:51, Cornelia Huck wrote:
>>>> vfio-ap devices do not pin any pages in the host. Therefore, they
>>>> are belived to be compatible with memory ballooning.
>>>>
>>>> Flag them as compatible, so both vfio-ap and a balloon can be
>>>> used simultaneously.
>>>>
>>>> Signed-off-by: Cornelia Huck <address@hidden>
>>>> ---
>>>>
>>>> As briefly discussed on IRC. RFC as I do not have easy access to
>>>> hardware I can test this with.
>>>>
>>>> ---
>>>>  hw/vfio/ap.c | 8 ++++++++
>>>>  1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/hw/vfio/ap.c b/hw/vfio/ap.c
>>>> index 65de952f44..3bf48eed28 100644
>>>> --- a/hw/vfio/ap.c
>>>> +++ b/hw/vfio/ap.c
>>>> @@ -104,6 +104,14 @@ static void vfio_ap_realize(DeviceState *dev, Error 
>>>> **errp)
>>>>      vapdev->vdev.name = g_strdup_printf("%s", mdevid);
>>>>      vapdev->vdev.dev = dev;
>>>>  
>>>> +    /*
>>>> +     * vfio-ap devices are believed to operate in a way compatible with
>>>> +     * memory ballooning, as no pages are pinned in the host.
>>>> +     * This needs to be set before vfio_get_device() for vfio common to
>>>> +     * handle the balloon inhibitor.
>>>> +     */
>>>> +    vapdev->vdev.balloon_allowed = true;
>>>> +
>>>>      ret = vfio_get_device(vfio_group, mdevid, &vapdev->vdev, &local_err);
>>>>      if (ret) {
>>>>          goto out_get_dev_err;
>>>>   
>>>
>>> What happens if this ever changes? Shouldn't we have an API to at least
>>> check what the vfio device can guarantee?
>>>
>>> "are believed to operate" doesn't sound like guarantees to me :)
> 
> I would actually remove that comment or fix it. We either know or we dont.
> In the way vfio-works I see no reason to disallow balloon. Even if the guest 
> does
> something wrong (e.g. crypto I/O on freed pages) the host would handle that 
> the
> same as it would for normal page accesses. From a host point of view the 
> crypto
> instructions are just CISC instructions with load/store semantics.

As long as vfio-ap does not and will never pin pages (and keep them
pinned), we are fine. I don't know about the details, but if vfio-ap
really just issues a synchronous instruction for us, we are fine.

> 
>>
>> It's the same for ccw :)
>>
>> While such an API definitely sounds like a good idea, it is probably
>> overkill to introduce it for this case (do we envision changing the way
>> vfio-ap operates in the future to make that statement non-true?)
> 
> agreed. 
>>
> 


-- 

Thanks,

David / dhildenb