* [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).