All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 2/5] x86/HVM: fix direct PCI port I/O emulation retry and error handling
Date: Tue, 8 Oct 2013 19:13:08 +0100	[thread overview]
Message-ID: <52544B34.4080305@citrix.com> (raw)
In-Reply-To: <5249917002000078000F807B@nat28.tlf.novell.com>

On 30/09/13 13:57, Jan Beulich wrote:
> dpci_ioport_{read,write}() guest memory access failure handling should
> be modelled after process_portio_intercept()'s (and others): Upon
> encountering an error on other than the first iteration, the count
> successfully handled needs to be stored and X86EMUL_OKAY returned, in
> order for the generic instruction emulator to update register state
> correctly before reporting failure or retrying (both of which would
> only happen after re-invoking emulation).
>
> Further we leverage (and slightly extend, due to the above mentioned
> need to return X86EMUL_OKAY) the "large MMIO" retry model.
>
> Note that there is still a special case not explicitly taken care of
> here: While the first retry on the last iteration of a "rep ins"
> correctly recovers the already read data, an eventual subsequent retry
> is being handled by the pre-existing mmio-large logic (through
> hvmemul_do_io() storing the [recovered] data [again], also taking into
> consideration that the emulator converts a single iteration "ins" to
> ->read_io() plus ->write()).
>
> Also fix an off-by-one in the mmio-large-read logic, and slightly
> simplify the copying of the data.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

One trivial thought comes to mind which you could easily do when
committing the patch...

> @@ -316,22 +325,51 @@ static int dpci_ioport_read(uint32_t mpo
>  
>          if ( p->data_is_ptr )
>          {
> -            int ret;
> -            ret = hvm_copy_to_guest_phys(p->data + step * i, &data, p->size);
> -            if ( (ret == HVMCOPY_gfn_paged_out) ||
> -                 (ret == HVMCOPY_gfn_shared) )
> -                return X86EMUL_RETRY;
> +            switch ( hvm_copy_to_guest_phys(p->data + step * i,
> +                                            &data, p->size) )
> +            {
> +            case HVMCOPY_okay:
> +                break;
> +            case HVMCOPY_gfn_paged_out:
> +            case HVMCOPY_gfn_shared:
> +                rc = X86EMUL_RETRY;
> +                break;
> +            case HVMCOPY_bad_gfn_to_mfn:
> +                /* Drop the write as real hardware would. */
> +                continue;
> +            case HVMCOPY_bad_gva_to_gfn:
> +                ASSERT(0);
> +                /* fall through */
> +            default:
> +                rc = X86EMUL_UNHANDLEABLE;
> +                break;
> +            }
> +            if ( rc != X86EMUL_OKAY)
> +                break;
>          }
>          else
>              p->data = data;
>      }
>      

Nuke the trailing whitespace on the line above here, which will
fractionally increase the size of the hunk below.

~Andrew

> -    return X86EMUL_OKAY;
> +    if ( rc == X86EMUL_RETRY )
> +    {
> +        vio->mmio_retry = 1;
> +        vio->mmio_large_read_bytes = p->size;
> +        memcpy(vio->mmio_large_read, &data, p->size);
> +    }
> +
> +    if ( i != 0 )
> +    {
> +        p->count = i;
> +        rc = X86EMUL_OKAY;
> +    }
> +
> +    return rc;
>  }
>  

  reply	other threads:[~2013-10-08 18:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-30 12:51 [PATCH 0/5] x86/HVM: XSA-63 follow-ups Jan Beulich
2013-09-30 12:57 ` [PATCH 1/5] x86/HVM: properly handle backward string instruction emulation Jan Beulich
2013-10-08 16:36   ` Andrew Cooper
2013-09-30 12:57 ` [PATCH 2/5] x86/HVM: fix direct PCI port I/O emulation retry and error handling Jan Beulich
2013-10-08 18:13   ` Andrew Cooper [this message]
2013-09-30 12:58 ` [PATCH 3/5] x86/HVM: don't ignore hvm_copy_to_guest_phys() errors during I/O intercept Jan Beulich
2013-10-08 18:20   ` Andrew Cooper
2013-10-09  7:48     ` Jan Beulich
2013-09-30 12:58 ` [PATCH 4/5] x86/HVM: properly deal with hvm_copy_*_guest_phys() errors Jan Beulich
2013-09-30 13:07   ` Andrew Cooper
2013-09-30 12:59 ` [PATCH 5/5] x86/HVM: cache emulated instruction for retry processing Jan Beulich
2013-10-10 11:35   ` Andrew Cooper
2013-12-18  8:36   ` Zhang, Yang Z
2013-12-18  8:48     ` Jan Beulich
2013-12-18  9:40       ` Zhang, Yang Z
2013-12-18 10:53         ` Jan Beulich
2013-12-24 11:29           ` Zhang, Yang Z
2014-01-07  8:28             ` Jan Beulich
2014-01-07  8:54               ` Zhang, Yang Z
2014-01-07  9:43                 ` Egger, Christoph
2014-01-08  5:50                   ` Zhang, Yang Z
2014-01-09 12:19                     ` Egger, Christoph
2014-01-16  4:42                       ` Zhang, Yang Z
2014-01-16  8:23                         ` Jan Beulich
2014-01-17  2:53                           ` Zhang, Yang Z
2013-10-08 15:10 ` Ping: [PATCH 0/5] x86/HVM: XSA-63 follow-ups Jan Beulich
2013-10-14  7:29 ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52544B34.4080305@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.