Re: [PATCH] QEMU support for virtio balloon driver

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Anthony Liguori wrote:
>>>>       
>>> 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).
>

Zapping the mmu is needed so the memory can actually be reclaimed in the 
absence of mmu notifiers.  With mmu notifiers, it is unnecessary.


>
> 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().
>

Or maybe

   stop all vcpus (in userspace)
   zap shadow
   madvise()
   resume all vcpus

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
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/