qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 1/1] balloon: add a feature bit to let Guest OS deflate balloon on oom
Date: Mon, 15 Jun 2015 12:10:05 +0200

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.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]