Re: [PATCH 2/2] virtio_balloon: export 'available' memory to balloon statistics

["Denis V. Lunev" <den@openvz.org>]

On 02/23/2016 06:53 PM, Michael S. Tsirkin wrote:
> On Tue, Feb 23, 2016 at 06:26:47PM +0300, Denis V. Lunev wrote:
>> On 02/23/2016 06:10 PM, Michael S. Tsirkin wrote:
>>> On Tue, Feb 16, 2016 at 06:50:52PM +0300, Denis V. Lunev wrote:
>>>> From: Igor Redko <redkoi@virtuozzo.com>
>>>>
>>>> Add a new field, VIRTIO_BALLOON_S_AVAIL, to virtio_balloon memory
>>>> statistics protocol, corresponding to 'Available' in /proc/meminfo.
>>>>
>>>> It indicates to the hypervisor how big the balloon can be inflated
>>>> without pushing the guest system to swap.
>>>>
>>>> Signed-off-by: Igor Redko <redkoi@virtuozzo.com>
>>>> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
>>>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>>>> CC: Michael S. Tsirkin <mst@redhat.com>
>>>> CC: Andrew Morton <akpm@linux-foundation.org>
>>> Oops - I missed the fact that this affects host/guest ABI.
>>>
>>> Can you please submit ABI update proposal to virtio tc?
>>> Spec patch would be even better.
>>>
>>> This is important to ensure there are no conflicts
>>> with other features being developed in parallel.
>> hmmm
>>
>>  From my point of view ABI remains untouched.
> Anything exposed by guest to host is ABI.
> Once we add stuff there, we never can remove it
> as some host might rely on it.
>
>> The guest can send any amount of <tag>;<value>
>> pairs and unknown tags are properly ignored
>> by the host.
>>
>> That is why I think that this change is safe.
> What happens if someone uses the tag you
> used for VIRTIO_BALLOON_S_AVAIL, for some
> other purpose?
> Any tools using VIRTIO_BALLOON_S_AVAIL will be confused.
actually this constant resides in QEMU only,
values are reported above using JSON and
string tags.

> Really, it's not hard to get a tag number from virtio TC,
> so please just do this.
>
ok. So do you propose to negotiate maximum allowed
tag to send at the driver start time?

we will have to guard this exchange with proper flag
in feature space then. This could be done but from my
point of view this looks like serious over-complication.
Do we have somebody who can judge?

Den