Re: [Qemu-devel] [PATCH 1/1] balloon: add a feature bit to let Guest OS deflate balloon on oom

[Christian Borntraeger <borntraeger@de.ibm.com>]

Am 15.06.2015 um 12:10 schrieb Michael S. Tsirkin:
> On Mon, Jun 15, 2015 at 11:59:05AM +0200, Christian Borntraeger wrote:
>> Am 15.06.2015 um 11:06 schrieb Michael S. Tsirkin:
>>
>>>>> AFAIK management tools depend on balloon not deflating
>>>>> below host-specified threshold to avoid OOM on the host.
>>>>> So I don't think we can make this a default,
>>>>> management needs to enable this explicitly.
>>>>
>>>> If the ballooning is required to keep the host memory managedment
>>>> from OOM - iow abusing ballooning as memory hotplug between guests
>>>> then yes better let the guest oom - that makes sense.
>>>>
>>>> Now: I think that doing so (not having enough swap in the host if
>>>> all guests deflate) and relying on balloon semantics is fundamentally
>>>> broken. Let me explain this: The problem is that we rely on guest
>>>> cooperation for the host integrity. As I explained  using madvise 
>>>> WONT_NEED will replace the current PTEs with invalid/emtpy PTEs. As
>>>> soon as the guest kernel re-touches the page (e.g. a malicious 
>>>> kernel module - not the balloon driver) it will be backed by the VMAs
>>>> default method - so usually with a shared R/O copy of the empty
>>>> zero page. Write accesses will result in a copy-on-write and allocate
>>>> new memory in the host. 
>>>> There is nothing we can do in the balloon protocol to protect the host
>>>> against malicious guests allocating all the maximum memory.
>>>
>>> If we want to try and harden host, we can unmap it so guest will crash
>>> if it touches pages without deflate.
>>>
>>>> If you need host integrity against guest memory usage, something like
>>>> cgroups_memory or so is probably the only reliable way.
>>>
>>> In the original design, protection against a malicious guest is not the
>>> point of the balloon, it's a technology that let you overcommit
>>> cooperative guests.
>>
>> Sure. But then its perfectly fine to let the guest reclaim by default,
>> because your statement 
>> "AFAIK management tools depend on balloon not deflating
>>  below host-specified threshold to avoid OOM on the host.
>>  So I don't think we can make this a default,
>>  management needs to enable this explicitly."
>>
>> is not true ;-)
>>
>> Christian
> 
> I don't see the connection.
> Deflate on OOM means "it's OK to deflate if you like, this won't
> cause any harm". If you set this flag, you can't overcommit host too
> agressively even with cooperative guests.

The connection is that there is no fundamental issue being solved that
requires the setting to be off or on. (both is ok with pros and cons)
Keeping reclaim on oom off has of course the lowest impact as it is
just todays behaviour - so we play safe.

I personally can live fine with both defaults and in the end its up to
you to decide as virtio maintainer. (my personal opinion to have deflate on
OOM=yes, MUST_TELL_HOST=off still stands, though)

Just keep in mind that you add an interface that we will drag along forever
and that we might require all future user to add a statement to libvirt
to do the right thing. So we better make up our mind which default value
has the bigger downsides. If that decision making process comes to the
conclusion to do it like this patch - fine with me. 

Christian