All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
	'Jan Beulich' <JBeulich@suse.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/HVM: fix interaction between internal and extern emulation
Date: Tue, 28 Nov 2017 11:58:21 +0000	[thread overview]
Message-ID: <7ecacb57da7e4930882bd8b6d74c7fde@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <24a625b30190424dad7aa3b8699185db@AMSPEX02CL03.citrite.net>

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 28 November 2017 11:31
> To: 'Jan Beulich' <JBeulich@suse.com>
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Julien Grall
> <julien.grall@arm.com>; xen-devel <xen-devel@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH] x86/HVM: fix interaction between internal
> and extern emulation
> 
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: 28 November 2017 11:26
> > To: Paul Durrant <Paul.Durrant@citrix.com>
> > Cc: Julien Grall <julien.grall@arm.com>; Andrew Cooper
> > <Andrew.Cooper3@citrix.com>; xen-devel <xen-
> > devel@lists.xenproject.org>
> > Subject: RE: [PATCH] x86/HVM: fix interaction between internal and extern
> > emulation
> >
> > >>> On 28.11.17 at 12:06, <Paul.Durrant@citrix.com> wrote:
> > > Yes, it appears that mmio_retry is only set when the underlying
> emulation
> > > returned X86EMUL_OKAY but not all reps were completed. If the
> > underlying
> > > emulation did not return X86EMUL_RETRY then I can't figure out why
> > > vio->io_completion should need to be set to anything other than
> > > HVMIO_no_completion since any other return value indicates there
> should
> > be
> > > nothing pending.
> >
> > So am I getting it right that you're suggesting to remove the
> > mmio_retry part of the condition in hvm_emulate_one_insn()?
> > That looks like it might work (I was previously only considering
> > to get rid of mmio_retry altogether, and that didn't look like a
> > viable route).
> 
> Yes, that's what I'm suggesting. I really can't see why it is needed. It could
> have been a mistake in my original patches or a semantic change in a
> subsequent patch, but it certainly looks wrong in current context.
> Andrew has just sent me his xtf repro so I'll give the change a go with that.

Yes, this patch fixed the problem for me. I'll do some more tests to check for collateral damage now... If it's all good, do you want me to submit it or do you want to send it as a v2 of your patch?

  Paul

diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index e449b4196e..9d9e1b0e40 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -88,7 +88,7 @@ bool hvm_emulate_one_insn(hvm_emulate_validate_t *validate, const char *descr)

     rc = hvm_emulate_one(&ctxt);

-    if ( hvm_vcpu_io_need_completion(vio) || vio->mmio_retry )
+    if ( hvm_vcpu_io_need_completion(vio) )
         vio->io_completion = HVMIO_mmio_completion;
     else
         vio->mmio_access = (struct npfec){};
diff --git a/xen/arch/x86/hvm/vmx/realmode.c b/xen/arch/x86/hvm/vmx/realmode.c
index 03dea6c0fc..11211c8cd8 100644
--- a/xen/arch/x86/hvm/vmx/realmode.c
+++ b/xen/arch/x86/hvm/vmx/realmode.c
@@ -103,7 +103,7 @@ void vmx_realmode_emulate_one(struct hvm_emulate_ctxt *hvmemul_ctxt)

     rc = hvm_emulate_one(hvmemul_ctxt);

-    if ( hvm_vcpu_io_need_completion(vio) || vio->mmio_retry )
+    if ( hvm_vcpu_io_need_completion(vio) )
         vio->io_completion = HVMIO_realmode_completion;

     if ( rc == X86EMUL_UNHANDLEABLE )

> 
>   Paul
> 
>   Paul
> 
> >
> > Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2017-11-28 11:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27  8:28 [PATCH] x86/HVM: fix interaction between internal and extern emulation Jan Beulich
2017-11-27 11:59 ` Andrew Cooper
2017-11-28  9:49 ` Paul Durrant
2017-11-28 10:02   ` Jan Beulich
2017-11-28 10:05     ` Paul Durrant
2017-11-28 10:16       ` Jan Beulich
2017-11-28 10:22         ` Paul Durrant
2017-11-28 10:40           ` Jan Beulich
2017-11-28 11:01             ` Paul Durrant
2017-11-28 11:06               ` Paul Durrant
2017-11-28 11:26                 ` Jan Beulich
2017-11-28 11:30                   ` Paul Durrant
2017-11-28 11:58                     ` Paul Durrant [this message]
2017-11-28 12:03                       ` Jan Beulich
2017-11-28 13:20                         ` Paul Durrant

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=7ecacb57da7e4930882bd8b6d74c7fde@AMSPEX02CL03.citrite.net \
    --to=paul.durrant@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=julien.grall@arm.com \
    --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.