From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tim Deegan <tim@xen.org>
Subject: Re: [PATCH 2 of 3] x86/emulate: Relieve contention of
	p2m lock in emulation of rep movs
Date: Wed, 25 Apr 2012 13:54:11 +0100
Message-ID: <20120425125411.GF51354@ocelot.phlegethon.org>
References: <patchbomb.1335296050@xdev.gridcentric.ca>
	<2ffc676120b8b1e4c456.1335296052@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <2ffc676120b8b1e4c456.1335296052@xdev.gridcentric.ca>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.com>, andres@gridcentric.ca, keir@xen.org, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

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@lagarcavilla.org>
> 
> 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.