Anthony Liguori wrote:
> Izik Eidus wrote:
>> Anthony Liguori wrote:
>>> Izik Eidus wrote:
>>>> Izik Eidus wrote:
>>>>> Anthony Liguori wrote:
>>>>>> Izik Eidus wrote:
>>>>>>>
>>>>>>> @@ -1058,8 +1038,27 @@ struct page *gfn_to_page(struct kvm *kvm,
>>>>>>> gfn_t gfn)
>>>>>>>
>>>>>>> gfn = unalias_gfn(kvm, gfn);
>>>>>>> slot = __gfn_to_memslot(kvm, gfn);
>>>>>>> - if (!slot)
>>>>>>> + if (!slot) {
>>>>>>> + get_page(bad_page);
>>>>>>> return bad_page;
>>>>>>> + }
>>>>>>> + if (slot->user_alloc) {
>>>>>>> + struct page *page[1];
>>>>>>> + int npages;
>>>>>>> +
>>>>>>> + down_read(¤t->mm->mmap_sem);
>>>>>>> + npages = get_user_pages(current, current->mm,
>>>>>>> + slot->userspace_addr
>>>>>>> + + (gfn - slot->base_gfn) * PAGE_SIZE, 1,
>>>>>>> + 1, 0, page, NULL);
>>>>>>> + up_read(¤t->mm->mmap_sem);
>>>>>>> + if (npages != 1) {
>>>>>>> + get_page(bad_page);
>>>>>>> + return bad_page;
>>>>>>> + }
>>>>>>> + return page[0];
>>>>>>>
>>>>>>
>>>>>> Wouldn't it be necessary to assign page[0] to slot->phys_mem[gfn
>>>>>> - slot->base_gfn]?
>>>>>
>>>> sorry, it seems like i missunderstand you in the answer i gave you.
>>>> it wouldnt be necessary to assign page[0] to slot->phys_mem[gfn -
>>>> slot->base_gfn], beacuse phys_mem wont have any memory allocate by
>>>> this time.
>>>>
>>>> with this patch, we are not holding anymore (when using userspace
>>>> allocation) array of all the memory at phys_mem.
>>>> beacuse now that the pages are swappable, the physical address
>>>> pointed by the virtual address all the time change (for example
>>>> when swapping happn)
>>>> so no one promise us that slot->phys_mem[gfn - slot->base_gfn] will
>>>> really point to page holding the gfn page.
>>>>
>>>> so what we did, is throw away the phys_mem array (also nice beacuse
>>>> it waste less ram), and at runtime we are getting the pages by
>>>> using the virtual address
>>>> beacuse the reference of the page get increased, it promised us
>>>> that untill we release it point to the gfn (release it by doing
>>>> put_page)
>>>>
>>>> hope i was more clear this time :)
>>>
>>> Yes, that makes sense!
>>>
>>> I wonder if there's a more elegant way dealing with older
>>> userspaces. For instance, is there any reason why we can allocate a
>>> userspace memory region on behalf of userspace. That way swap would
>>> even work with older userspaces.
>> if we can do that, yes swap will work on older userspace.
>
> I think it's just a matter of calling do_mmap() with the appropriate
> parameters. It looks likes there's some drivers call do_mmap() directly.
>
yea, i think you right, this is excellent idea!, when we will merge the
swapping to kvm, we will add swapping support to older userspace.
-------------------------------------------------------------------------
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
