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.
Regards,
Anthony Liguori
>> 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
