From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: possible I/O emulation state machine issue
Date: Wed, 28 Mar 2018 13:48:22 +0000 [thread overview]
Message-ID: <af3e3bd283ec4ad89fc8bcfc956d3f1d@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <5AB8CE9602000078001B5F5F@prv1-mh.provo.novell.com>
> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 26 March 2018 09:43
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; xen-devel <xen-
> devel@lists.xenproject.org>
> Subject: Re: possible I/O emulation state machine issue
>
> >>> On 23.03.18 at 14:41, <Paul.Durrant@citrix.com> wrote:
> > So somehow it appears the vcpu got back into guest and executed the next
> > instruction whilst there was pending I/O.
>
> Two new pieces of information, in case either rings a bell:
>
Alas neither rings a bell.
> The issue appears to never occur in hap=0 mode.
>
That's quite an odd correlation.
> After having added I/O emulation state checks at the beginning of
> vmx_vmexit_handler() as well as very early and very late in
> vmx_vmenter_helper(), it was the one early in
> vmx_vmenter_helper() which triggered (still seeing the VGA port
> access in STATE_IORESP_READY while vio->io_completion was
> HVMIO_no_completion).
>
The same test is used (hvm_vcpu_io_need_completion()) in handle_pio() to set the completion handler and in hvm_io_assist() to set the state to IORESP_READY. The only place the internal state gets set to IORESP_READY is in hvm_io_assist() so the fact that you see a disparity between the state and the completion handler is very odd. Perhaps it might be worth adding an ASSERT into hvm_io_assist() to ensure there really is a completion handler in place before setting the internal state to IORESP_READY would be worthwhile.
Paul
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-03-28 13:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-22 15:12 possible I/O emulation state machine issue Jan Beulich
2018-03-22 15:29 ` Andrew Cooper
2018-03-23 7:30 ` Jan Beulich
2018-03-23 10:43 ` Paul Durrant
2018-03-23 11:19 ` Jan Beulich
2018-03-23 11:35 ` Jan Beulich
2018-03-23 13:41 ` Paul Durrant
2018-03-23 15:09 ` Jan Beulich
2018-03-26 8:42 ` Jan Beulich
2018-03-28 13:48 ` Paul Durrant [this message]
2018-03-28 14:08 ` Jan Beulich
2018-03-28 14:20 ` Paul Durrant
2018-03-28 15:32 ` Jan Beulich
2018-03-28 15:59 ` Jan Beulich
2018-03-28 16:22 ` Paul Durrant
2018-03-28 16:35 ` Andrew Cooper
2018-03-29 6:31 ` Jan Beulich
2018-04-12 14:13 ` Jan Beulich
2018-03-29 6:27 ` Jan Beulich
2018-03-29 8:42 ` Paul Durrant
2018-03-29 8:51 ` Jan Beulich
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=af3e3bd283ec4ad89fc8bcfc956d3f1d@AMSPEX02CL03.citrite.net \
--to=paul.durrant@citrix.com \
--cc=Andrew.Cooper3@citrix.com \
--cc=JBeulich@suse.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.