Re: [Xen-devel] possible I/O emulation state machine issue

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 28 March 2018 15:08
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-devel <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: RE: possible I/O emulation state machine issue
> 
> >>> On 28.03.18 at 15:48, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 26 March 2018 09:43
> >>
> >> 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.
> 
> Further extended logging appears to confirm there's no issue in that
> direction. While I haven't been able to draw useful conclusions from
> that further logging (towards a fix), the exact conditions when this
> triggers have become more clear: It's the last iteration of a REP OUTSW
> to either of the two VGA port ranges stdvga.c intercepts, and I've
> begun to think it might be connected to the way the insn emulator
> deals with such single-iteration operations (breaking them up into a
> memory read and an I/O write in the case here).
> 

It looks to me like (unless there's a page boundary issue) the rep outsw is 
probably only being broken up because of the stdvga caching (which will return 
'unhandleable' in the middle of the intercept loop and thus force a 
truncation). If you disable caching and let the full rep ioreq make it out to 
QEMU, does the issue go away?

  Paul

> I've simulated this by way of an XTF test, though, and all is fine
> there. Together with this not being reliable to reproduce (guest
> crashes in one of 5-10 attempts) there clearly must be some other
> factor here.
> 
> One thing I started to wonder about is why we run these insns
> through the full emulator in the first place. But perhaps that's just
> because we hope this code won't be used much, and hence the
> simplest possible solution code-wise ought to do.
> 
> Jan


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