xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Don't take the domain lock for p2m operations.
@ 2013-07-29 11:20 Tim Deegan
  0 siblings, 0 replies; 3+ messages in thread
From: Tim Deegan @ 2013-07-29 11:20 UTC (permalink / raw)
  To: xen-devel; +Cc: keir, jbeulich

P2M ops are covered by their own locks, and these uses of the domain
lock are relics of shadow-v1 code.

Signed-off-by: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm.c   |    9 +++------
 xen/common/memory.c |    4 ----
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c00841c..e7f0e13 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4596,11 +4596,6 @@ static int xenmem_add_to_physmap_once(
         return -EINVAL;
     }
 
-    domain_lock(d);
-
-    if ( page )
-        put_page(page);
-
     /* Remove previously mapped page if it was present. */
     prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt));
     if ( mfn_valid(prev_mfn) )
@@ -4631,7 +4626,9 @@ static int xenmem_add_to_physmap_once(
     if ( xatp->space == XENMAPSPACE_gmfn ||
          xatp->space == XENMAPSPACE_gmfn_range )
         put_gfn(d, gfn);
-    domain_unlock(d);
+
+    if ( page )
+        put_page(page);
 
     return rc;
 }
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 06a0d0a..50b740f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -693,8 +693,6 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
             return rc;
         }
 
-        domain_lock(d);
-
         page = get_page_from_gfn(d, xrfp.gpfn, NULL, P2M_ALLOC);
         if ( page )
         {
@@ -704,8 +702,6 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
         else
             rc = -ENOENT;
 
-        domain_unlock(d);
-
         rcu_unlock_domain(d);
 
         break;
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] Don't take the domain lock for p2m operations.
       [not found] <mailman.5.1375099203.24730.xen-devel@lists.xen.org>
@ 2013-07-29 13:31 ` Andres Lagar-Cavilla
  2013-07-29 14:02   ` Tim Deegan
  0 siblings, 1 reply; 3+ messages in thread
From: Andres Lagar-Cavilla @ 2013-07-29 13:31 UTC (permalink / raw)
  To: xen-devel, Tim Deegan

> P2M ops are covered by their own locks, and these uses of the domain
> lock are relics of shadow-v1 code.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
Reviewed-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

What about other uses of the domain lock? Should a subsequent patch be cut, or this one expanded?

By my count, the following uses of the domain lock in mm code could be abolished or replaced by the p2m lock:
* ARM's xenmem_add_to_physmap_once
* emulation of cr3 write (traps.c)
* And possibly x86's do_set_gdt, although I'm unclear about it

That would leave the domain lock only to protect vcpu related ops.

My 0.02
Andres

> ---
> xen/arch/x86/mm.c   |    9 +++------
> xen/common/memory.c |    4 ----
> 2 files changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index c00841c..e7f0e13 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4596,11 +4596,6 @@ static int xenmem_add_to_physmap_once(
>         return -EINVAL;
>     }
> 
> -    domain_lock(d);
> -
> -    if ( page )
> -        put_page(page);
> -
>     /* Remove previously mapped page if it was present. */
>     prev_mfn = mfn_x(get_gfn(d, xatp->gpfn, &p2mt));
>     if ( mfn_valid(prev_mfn) )
> @@ -4631,7 +4626,9 @@ static int xenmem_add_to_physmap_once(
>     if ( xatp->space == XENMAPSPACE_gmfn ||
>          xatp->space == XENMAPSPACE_gmfn_range )
>         put_gfn(d, gfn);
> -    domain_unlock(d);
> +
> +    if ( page )
> +        put_page(page);
> 
>     return rc;
> }
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 06a0d0a..50b740f 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -693,8 +693,6 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>             return rc;
>         }
> 
> -        domain_lock(d);
> -
>         page = get_page_from_gfn(d, xrfp.gpfn, NULL, P2M_ALLOC);
>         if ( page )
>         {
> @@ -704,8 +702,6 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>         else
>             rc = -ENOENT;
> 
> -        domain_unlock(d);
> -
>         rcu_unlock_domain(d);
> 
>         break;
> -- 
> 1.7.10.4

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Don't take the domain lock for p2m operations.
  2013-07-29 13:31 ` Andres Lagar-Cavilla
@ 2013-07-29 14:02   ` Tim Deegan
  0 siblings, 0 replies; 3+ messages in thread
From: Tim Deegan @ 2013-07-29 14:02 UTC (permalink / raw)
  To: Andres Lagar-Cavilla; +Cc: xen-devel

At 09:31 -0400 on 29 Jul (1375090283), Andres Lagar-Cavilla wrote:
> > P2M ops are covered by their own locks, and these uses of the domain
> > lock are relics of shadow-v1 code.
> > 
> > Signed-off-by: Tim Deegan <tim@xen.org>
> Reviewed-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> What about other uses of the domain lock? Should a subsequent patch be cut, or this one expanded?
> 
> By my count, the following uses of the domain lock in mm code could be abolished or replaced by the p2m lock:
> * ARM's xenmem_add_to_physmap_once

Oops, good point.  v2 coming, with that one removed too.

> * emulation of cr3 write (traps.c)

That one's already gone in the staging tree.

> * And possibly x86's do_set_gdt, although I'm unclear about it

I'd rather now, at least not in this patch.  That's part of the PV
interface, and nothing to to with x86/mm/p2m.

Cheers,

Tim.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-07-29 14:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-29 11:20 [PATCH] Don't take the domain lock for p2m operations Tim Deegan
     [not found] <mailman.5.1375099203.24730.xen-devel@lists.xen.org>
2013-07-29 13:31 ` Andres Lagar-Cavilla
2013-07-29 14:02   ` Tim Deegan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).