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
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel