Izik Eidus wrote:
>>  static void page_header_update_slot(struct kvm *kvm, void *pte, 
>> gpa_t gpa)
>>  {
>>      int slot = memslot_id(kvm, gfn_to_memslot(kvm, gpa >> PAGE_SHIFT));
>>
>> ------------------------------------------------------------------------- 
>>
>>   
> kvm_memory_slot
>
> heh, i am working on similir patch, and our gfn_to_page and the change 
> to  kvm_memory_slot even by varible names :)

Ah, fantastic :-)  Care to share what you currently have?

> few things you have to do to make this work:
> make gfn_to_page safe always function (return bad_page in case of 
> failure, i have patch for this if you want)

That seems pretty obvious.  No reason not to have that committed now.

> hacking the kvm_read_guest_page / kvm_write_guest_page 
> kvm_clear_guest_page to do put_page after the usage of the page

The idea being that kvm_read_guest_page() will effectively pin the page 
and put_page() has the effect of unpinning it?  It seems to me that we 
should be using page_cache_release()'ing since we're not just 
get_page()'ing the memory.  I may be wrong though.

Both of these are an optimization though.  It's not strictly needed for 
what I'm after since in the case of ballooning, there's no reason why 
someone would be calling kvm_read_guest_page() on the ballooned memory.

>
> secoend, is hacking the rmap to do reverse mapping to every present 
> pte and put_page() the pages at rmap_remove()
> and this about all, to make this work.

If I understand you correctly, this is to unpin the page whenever it is 
removed from the rmap?  That would certainly be useful but it's still an 
optimization.  The other obvious optimization to me would be to not use 
get_user_pages() on all memory to start with and instead, allow pages to 
be faulted in on use.  This is particularly useful for creating a VM 
with a very large amount of memory, and immediately ballooning down.  
That way the large amount of memory doesn't need to be present to actual 
spawn the guest.

Regards,

Anthony Liguori

>
>


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