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