Re: [PATCH] QEMU support for virtio balloon driver

[Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Dor Laor wrote:
> On Thu, 2008-01-24 at 16:29 -0600, Anthony Liguori wrote:
>   
>> Anthony Liguori wrote:
>>     
>>> This patch adds support to QEMU for Rusty's recently introduce virtio balloon
>>> driver.  The user-facing portions of this are the introduction of a "balloon"
>>> and "info balloon" command in the monitor.
>>>
>>> I think using madvise unconditionally is okay but I am not sure.
>>>       
>> Looks like it's not.  I just hung my host system after doing a bunch of 
>> ballooning with a kernel that doesn't have MM notifiers.
>>
>> I'm inclined to think that we should have a capability check for MM 
>> notifiers and just not do madvise if they aren't present.  I don't think 
>> the ioctl approach that Marcelo took is sufficient as a malicious guest 
>> could possibly hose the host.
>>
>>     
>
> The ioctl to zap the shadow pages is needed in order to free memory
> fast. Without it the balloon will evacuate memory to slow for common
> mgmt application (running additional VMs).
>   

I think that assertion needs some performance numbers to back it up.  
Linux will write unused pages to swap such that when it does need to 
obtain memory, it can easily just reclaim pages without doing any disk IO.

The real advantage with using madvise() is that it doesn't use any swap 
space (at least, on Linux).

> This ioctl (on older kernels only) can hose the host but so can
> malicious guests that do dummy cr3 switching and other hackry.
>   

What do you mean by that?  The guest really shouldn't be able to hose 
the host regardless of what it puts in cr3.  If it can, then that's a 
very serious bug.

> If one really insist he can always add a timer to this ioctl to slow
> potential malicious guests.
>   

The issue is the atomicity of removing some from the shadow MMU cache 
and then madvise()'ing (since madvise is incapable of evicting from the 
shadow MMU cache w/o MMU notifiers).  The only real solution I know of 
would be to also introduce an ioctl that's essentially, 
MADVISE_AND_REMOVE_FROM_SHADOW_MMU ioctl().

Regards,

Anthony Liguori

>   
>> Having the guest allocate and not touch memory means that it should 
>> eventually be removed from the shadow page cache and eventually swapped 
>> out so ballooning isn't totally useless in the absence of MM notifiers.
>>
>> Regards,
>>
>> Anthony Liguori
>>     
>
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/