[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly



>>> On 30.09.11 at 12:14, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> On 30/09/11 09:08, Jan Beulich wrote:
>>>>> On 29.09.11 at 18:45, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>>> On 29/09/11 17:07, Jan Beulich wrote:
>>>>>>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>>>>> [Resend as requested by Konrad.]
>>>>>
>>>>> This series of patches allows the vmalloc_sync_all() to be removed
>>>>> from alloc_vm_area() by getting the hypervisor to update the PTEs (in
>>>>> init_mm) directly rather than having the hypervisor look in the
>>>>> current page tables to find the PTEs.
>>>>>
>>>>> Once the hypervisor has updated the PTEs, the normal mechanism of
>>>>> syncing the page tables after a fault works as expected.
>>>>
>>>> Did you actually test that, and namely the case where alloc_vm_area()
>>>> would result in a new top level page directory entry to get populated?
>>>>
>>>> I cannot see how this new entry would propagate into other mm-s, and
>>>> hence I cannot see how you can do away with calling vmalloc_sync_all()
>>>> just by changing how leaf page table entries get populated.
>>>
>>> I don't think this new behaviour of alloc_vm_area() is any different
>>> from how a regular vmalloc() works.
>> 
>> Of course not. Callers of vmalloc() need to use vmalloc_sync_all() too
>> before it is permitted to access the allocated space from an NMI
>> handler or pass it into a hypercall.
> 
> The virtual addresses of the mapped rings are not accessed in an NMI
> handler or a hypercall (before this patch set they were accessed in the
> GNTTABOP_map_grant_ref hypercall, but no longer).
> 
> In the future, if something did want to pass the virtual address to a
> hypercall it wouldn't need the vmalloc_sync() as it could disable
> preemption, touch the page (so current->active_mm is updated), do the
> hypercall, then disable preemption.

And you verified that no other hypercall gets, perhaps indirectly,
passed alloc_vm_area()ed memory?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.