From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v5 09/16] x86/hvm: limit reps to avoid the
 need to handle retry
Date: Thu, 2 Jul 2015 18:10:33 +0100
Message-ID: <55957089.2020304@citrix.com>
References: <1435669558-5421-1-git-send-email-paul.durrant@citrix.com>
	<1435669558-5421-10-git-send-email-paul.durrant@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=61810cf3e=Andrew.Cooper3@citrix.com>)
	id 1ZAi0z-0004cq-Tk
	for xen-devel@lists.xenproject.org; Thu, 02 Jul 2015 17:11:10 +0000
In-Reply-To: <1435669558-5421-10-git-send-email-paul.durrant@citrix.com>
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: Paul Durrant <paul.durrant@citrix.com>, xen-devel@lists.xenproject.org
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

On 30/06/15 14:05, Paul Durrant wrote:
> @@ -235,7 +219,7 @@ static int hvmemul_do_io_buffer(
>  
>      BUG_ON(buffer == NULL);
>  
> -    rc = hvmemul_do_io(is_mmio, addr, reps, size, dir, df, 0,
> +    rc = hvmemul_do_io(is_mmio, addr, *reps, size, dir, df, 0,
>                         (uintptr_t)buffer);
>      if ( rc == X86EMUL_UNHANDLEABLE && dir == IOREQ_READ )
>          memset(buffer, 0xff, size);
> @@ -287,17 +271,53 @@ static int hvmemul_do_io_addr(
>      bool_t is_mmio, paddr_t addr, unsigned long *reps,
>      unsigned int size, uint8_t dir, bool_t df, paddr_t ram_gpa)
>  {
> -    struct page_info *ram_page;
> +    struct vcpu *v = current;

curr.

> +    unsigned long ram_gmfn = paddr_to_pfn(ram_gpa);

ram_gfn.

> +    unsigned int page_off = ram_gpa & (PAGE_SIZE - 1);

offset and ~PAGE_MASK.

> +    struct page_info *ram_page[2];
> +    int nr_pages = 0;

unsigned int.

> +    unsigned long count;
>      int rc;
>  
> -    rc = hvmemul_acquire_page(paddr_to_pfn(ram_gpa), &ram_page);
> +    rc = hvmemul_acquire_page(ram_gmfn, &ram_page[nr_pages]);
>      if ( rc != X86EMUL_OKAY )
> -        return rc;
> +        goto out;
>  
> -    rc = hvmemul_do_io(is_mmio, addr, reps, size, dir, df, 1,
> +    nr_pages++;
> +
> +    /* Detemine how many reps will fit within this page */
> +    count = min_t(unsigned long,
> +                  *reps,
> +                  df ?
> +                  (page_off + size - 1) / size :
> +                  (PAGE_SIZE - page_off) / size);
> +
> +    if ( count == 0 )
> +    {
> +        /*
> +         * This access must span two pages, so grab a reference to
> +         * the next page and do a single rep.
> +         */
> +        rc = hvmemul_acquire_page(df ? ram_gmfn - 1 : ram_gmfn + 1,
> +                                  &ram_page[nr_pages]);

All guest-based ways to trigger an IO spanning a page boundary will be
based on linear address.  If a guest has paging enabled, this movement
to an adjacent physical is not valid.  A new pagetable walk will be
required to determine the correct second page.

~Andrew