WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 4/6] mm: New XENMEM space, XENMAPSPACE_gmfn_range

On 10/11 09:54, Jan Beulich wrote:
> >>> On 10.11.11 at 09:44, Jean Guyader <jean.guyader@xxxxxxxxxxxxx> wrote:
> 
> In the native implementation I neither see the XENMAPSPACE_gmfn_range
> case getting actually handled in the main switch (did you mean to change
> xatp.space to XENMAPSPACE_gmfn in that case?), nor do I see how you
> communicate back how many of the pages were successfully processed in
> the event of an error in the middle of the processing or when a
> continuation is required.
> 

Yes, that is true. 

> But with the patch being pretty hard to read, maybe I'm simply
> overlooking something?
> 

Sorry about that, moving code arround doesn't really look code
on patches.

I now changed xenmem_add_to_physmap to take a pointer
on xatp so I can modify the argument directly (decrementing size and
incrementing gpfn and idx).
Then if xenmem_add_to_physmap return EGAIN I'll copy xtap back to
the guest handler and create the native continuation.
Also a case was missing for XENMAPSPACE_gmfn_range in xenmem_add_to_physmap.

> Further (I realize I should have commented on this earlier) I think that
> in order to allow forward progress you should not check for preemption
> on the very first iteration of each (re-)invocation. That would also
> guarantee no behavioral change to the original single-page variants.
> 

Agreed, I now only check for preemption in the case of new space
(XENMAPSPACE_gmfn_range), so the original behavior should be preserved.

> >--- a/xen/arch/x86/x86_64/compat/mm.c
> >+++ b/xen/arch/x86/x86_64/compat/mm.c
> >@@ -63,6 +63,16 @@ int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) 
> >arg)
> > 
> >         XLAT_add_to_physmap(nat, &cmp);
> >         rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
> >+        if ( rc < 0 )
> >+            return rc;
> >+
> >+        if ( rc == __HYPERVISOR_memory_op )
> >+            hypercall_xlat_continuation(NULL, 0x2, nat, arg);
> >+
> >+        XLAT_add_to_physmap(&cmp, nat);
> >+
> >+        if ( copy_to_guest(arg, &cmp, 1) )
> >+            return -EFAULT;
> 
> Other than in the XENMEM_[gs]et_pod_target you (so far, subject to the
> above comment resulting in a behavioral change) don't have any real
> outputs here, and hence there's no need to always to the outbound
> translation - i.e. all of this could be moved into the if ()'s body.
> 

Done.

Thanks for the review,
Jean

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