|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1 of 2] After preparing a page for page-in, allow immediate fill-in of the page contents
> Hi,
>
> This looks good to me. I think it needs two more things to make it
> correct (as well as the tools patch 2/2):
> - an update to the xenpaging tool to use the new interface; and
Sure, have it ready, will definitely cc Olaf for his ack on that one.
> - a possible update to the paging state machine --- after all, if the
> prep call allocates the pageand fills its contents, do we need
> any more stages on the page-in path?
I am kind of torn about this. Maybe the pager wants to do a set of loads,
and then fire off many vcpu unpauses in a batched fashion (which is
possible with patches I submitted later).
This isn't a necessity for correctness, though. And we still need the
resume kick for cases like a guest accessing a page that has not been
paged out yet (p2m_ram_paging_out)
Andres
>
> One more comment below:
>
> At 16:52 -0500 on 29 Nov (1322585560), Andres Lagar-Cavilla wrote:
>> diff -r 4ee6d40edc2c -r 0ce71e5bfaac xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -974,14 +974,43 @@ void p2m_mem_paging_populate(struct doma
>> * mfn if populate was called for gfn which was nominated but not
>> evicted. In
>> * this case only the p2mt needs to be forwarded.
>> */
>> -int p2m_mem_paging_prep(struct domain *d, unsigned long gfn)
>> +int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t
>> buffer)
>> {
>> struct page_info *page;
>> p2m_type_t p2mt;
>> p2m_access_t a;
>> - mfn_t mfn;
>> + mfn_t mfn, buf_mfn = _mfn(INVALID_MFN);
>> struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> - int ret;
>> + int ret, page_extant = 1;
>> + void *buf_map = NULL;
>> +
>> + /* Map buffer page, if any, and get a reference */
>> + if ( buffer )
>> + {
>> + l1_pgentry_t l1e;
>> + unsigned long buf_gfn;
>> + p2m_type_t buf_p2mt;
>> +
>> + if ( (buffer & (PAGE_SIZE - 1)) ||
>> + (!access_ok(buffer, PAGE_SIZE)) )
>> + return -EINVAL;
>> +
>> + guest_get_eff_l1e(current, buffer, &l1e);
>> + buf_gfn = l1e_get_pfn(l1e);
>> + buf_mfn = get_gfn(current->domain, buf_gfn,
>> + &buf_p2mt);
>> +
>> + if ( likely( mfn_valid(buf_mfn) &&
>> + p2m_is_ram(buf_p2mt) ) )
>> + {
>> + get_page(mfn_to_page(buf_mfn), current->domain);
>> + buf_map = map_domain_page(mfn_x(buf_mfn));
>> + put_gfn(current->domain, buf_gfn);
>> + } else {
>> + put_gfn(current->domain, buf_gfn);
>> + return -EINVAL;
>> + }
>> + }
>
> We could maybe avoid all this mechanism by doing a copy_from_user() of
> the buffer contents directly into the new page, instead of an explicit
> map-and-memcpy().
>
> Cheers,
>
> Tim.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |