Anthony Liguori wrote:
> Avi Kivity wrote:
>   
>> Anthony Liguori wrote:
>>   
>>     
>>> Now that we have userspace memory allocation, I wanted to play with 
>>> ballooning.
>>> The idea is that when a guest "balloons" down, we simply unpin the 
>>> underlying
>>> physical memory and the host kernel may or may not swap it.  To reclaim
>>> ballooned memory, the guest can just start using it and we'll pin it on 
>>> demand.
>>>
>>> The following patch is a stab at providing the right infrastructure for 
>>> pinning
>>> and automatic repinning.  I don't have a lot of comfort in the MMU code so I
>>> thought I'd get some feedback before going much further.
>>>
>>> gpa_to_hpa is a little awkward to hook, but it seems like the right place 
>>> in the
>>> code.  I'm most uncertain about the SMP safety of the unpinning.  
>>> Presumably,
>>> I have to hold the kvm lock around the mmu_unshadow and page_cache release 
>>> to
>>> ensure that another VCPU doesn't fault the page back in after mmu_unshadow?
>>>
>>>   
>>>     
>>>       
>> One we have true swapping capabilities (which imply ability for the
>> kernel to remove a page from the shadow page tables) you can unpin by
>> calling munmap() or madvise(MADV_REMOVE) on the pages to be unpinned.
>>   
>>     
>
> So does MADV_REMOVE remove the backing page but still allow for memory 
> to be faulted in?  That is, after calling MADV_REMOVE, there's no 
> guarantee that the contents of a give VA range will remain the same (but 
> it won't SEGV the app if it accesses that memory)?
>
>   

I think so.  The docs aren't clear.  See also MADV_DONTNEED.




-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to