Re: [Xen-devel] [PATCH 2 of 3] x86/emulate: Relieve contention of p2m lock in emulation of rep movs

[Tim Deegan <tim@xxxxxxx>]

At 15:34 -0400 on 24 Apr (1335281652), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/hvm/emulate.c |  27 +++++++++------------------
>  1 files changed, 9 insertions(+), 18 deletions(-)
> 
> 
> get_two_gfns is used to query the source and target physical addresses of the
> emulated rep movs. It is not necessary to hold onto the two gfn's for the
> duration of the emulation: further calls down the line will do the appropriate
> unsharing or paging in, and unwind correctly on failure.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
> 
> diff -r 58fd70123787 -r 2ffc676120b8 xen/arch/x86/hvm/emulate.c
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -714,25 +714,23 @@ static int hvmemul_rep_movs(
>      if ( rc != X86EMUL_OKAY )
>          return rc;
>  
> +    /* The query on the gfns is to establish the need for mmio. In the two 
> mmio
> +     * cases, a proper get_gfn for the "other" gfn will be enacted, with 
> paging in
> +     * or unsharing if necessary. In the memmove case, the gfn might change 
> given
> +     * the bytes mov'ed, and, again, proper get_gfn's will be enacted in
> +     * __hvm_copy. */ 
>      get_two_gfns(current->domain, sgpa >> PAGE_SHIFT, &sp2mt, NULL, NULL,
>                   current->domain, dgpa >> PAGE_SHIFT, &dp2mt, NULL, NULL,
>                   P2M_ALLOC, &tg);
> -
> +    put_two_gfns(&tg);

If we're just going to put_ these immediately, we don't need to use
get_two_gfns().

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel