Re: [PATCH 0/4] Swapping

[Izik Eidus <izike-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Anthony Liguori wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>> Izik Eidus wrote:
>>>> Anthony Liguori wrote:
>>>>> I've been playing around with these patches.  If I do an 
>>>>> madvise(MADV_DONTNEED) in userspace, when I close the VM, I get 
>>>>> the following bug.  My knowledge of the mm is limited but since 
>>>>> madvise(MADV_DONTNEED) effectively does a zap_page_range() I 
>>>>> wonder if we're lacking the necessary callback to also remove any 
>>>>> potential GPA covered by that range from shadow page cache.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Anthony Liguori
>>>> it probably beacuse the changes of the first patch, ( that make all 
>>>> present shadow pages rmapped )
>>>> Anthony can you please check what happn if you run latest kvm with 
>>>> the patch (of the rmap) and without the patch?
>>>
>>> It looks like it's my patch for doing an in kernel mmap() to support 
>>> older userspaces.  I'll figure out what the problem is.
>>>
>>> But at any rate, would madvise() be able to evict the current 
>>> contents of something in the shadow page cache or will the guest not 
>>> pick up the new memory until the old gets evicted from the shadow 
>>> page cache?
>> if i understand you right, then madvise() wont harm us, beacuse we 
>> protect all our shadow memory by removing the writable bit from it.
>> therefor the guest cant change anything without we know it.
>
> 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





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