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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
