On 05.12.2018 17:45, Cornelia Huck wrote:
> On Wed, 5 Dec 2018 17:38:22 +0100
> David Hildenbrand <da...@redhat.com> 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 <coh...@redhat.com>
>>> ---
>>>
>>> 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.
>
> 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.
>
