Re: [PATCH 0/4] Swapping

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

Anthony Liguori wrote:
> Izik Eidus wrote:
>   
>>> That's not quite what I was wondering.
>>>
>>> When you do an madvise() in userspace, the result is that when that 
>>> memory is accessed again, linux will demand-fault in a zero page and 
>>> COW it appropriately.  If we do madvise() on the VA representing 
>>> guest physical memory, what I'm curious about is whether the guest 
>>> will actually see this change.  If the guest happens to have the page 
>>> mapped before we do the madvise(), what triggers KVM to kick any 
>>> shadow page table entries out of it's cache?
>>>
>>> IIUC, today, after the madvise, the guest will have access to the old 
>>> page until that entry gets evicted and reloaded from the shadow page 
>>> table cache.
>>>       
>> ok i am no familier with madvise() so i might talk nonsense but,
>> if the guest have the page mapped before the madvise(), this mean we 
>> have high refernce to it, this is our only protection and as far as i 
>> understand this should be enough
>>     
>
> Right, we will have a reference to the page.  But we want to propagate 
> this change to the guest.   So madvise() may be a bad example.
>
> What if you wanted to do shared memory for multiple guests.  You start 
> out with an anonymous mmap(), and you now what to mmap() a file in 
> /dev/shm to be shared among multiple guests so you mmap(MAP_FIXED) to 
> phys_ram_base + guest_pa in each guest.
>
> So what if guest_pa was in the guest's shadow page cache?  In order for 
> the guest to see the right hpa (the new shared memory), we have to be 
> able to evict guest_pa.  We could do this with something like 
> mmu_unshadow().
>
> What I don't understand, is how we can have something like 
> mmu_unshadow() called automatically when an mmap() is initiated from 
> userspace.  We could just add an ioctl() to do it from userspace but I 
> think it would be nicer if it Just Worked.
>   

Behold the magic of pte notifiers!  Every time the host touches a host 
page table entry, it calls kvm which zaps the corresponding shadow pte 
entries and invalidates any tlb entries in running vcpus.

-- 
error compiling committee.c: too many arguments to function


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