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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
> Of Jan Beulich
> Sent: 23 March 2018 11:36
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-devel <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] possible I/O emulation state machine issue
> 
> >>> On 23.03.18 at 11:43, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On
> Behalf
> >> Of Jan Beulich
> >> Sent: 23 March 2018 07:30
> >>
> >> >>> On 22.03.18 at 16:29, <andrew.cooper3@xxxxxxxxxx> wrote:
> >> > On 22/03/18 15:12, Jan Beulich wrote:
> >> >> Paul,
> >> >>
> >> >> our PV driver person has found a reproducible crash with ws2k8,
> >> >> triggered by one of the WHQL tests. The guest get crashed because
> >> >> the re-issue check of an ioreq close to the top of hvmemul_do_io()
> >> >> fails. I've handed him a first debugging patch, output of which
> >> >> suggests that we're dealing with a completely new request, which
> >> >> in turn would mean that we've run into stale STATE_IORESP_READY
> >> >> state:
> >> >>
> >> >> (XEN) d2v3: t=0/1 a=3c4/fed000f0 s=2/4 c=1/1 d=0/1 f=0/0 p=0/0
> >> > v=100/ffff831873f27a30
> >> >> (XEN) ----[ Xen-4.10.0_15-0  x86_64  debug=n   Tainted:  C   ]----
> >> >
> >> > Irrespective of the issue at hand, can testing be tried with a debug
> >> > build to see if any of the assertions are hit?
> >>
> >> Nothing, unfortunately. But at least the stack trace can be relied
> >> upon this way.
> >
> >   I'm assuming the debug line above is indicating the former emulation
> > before the '/' and the latter after? In which case it looks like an MMIO to
> > the HPET (I think that's what's at 0xfed000f0) clashing with a port IO to 
> > the
> > graphics device. So, why is the HPET emulation making it to QEMU? Are you
> > trying to run Windows with Xen's HPET emulation turned on?
> 
> Actually I think I'm confused by your reply. Why are you talking about
> qemu? Said check sits above hvm_io_intercept(), so the code in question
> runs for both internally handled and forwarded requests. The question
> for me rather is why we see a HPET access when the prior VGA one
> apparently wasn't fully finished yet.

Ah that's true. We will do the check based on the response state even if the 
next IO is going to be dealt with internally. So, yes, the real question is why 
the previous I/O was completed without apparently waiting for QEMU to finish.
We should have sent the VGA PIO out to QEMU, resulting in 
hvm_vcpu_io_need_completion() returning true in handle_pio() meaning that 
vio->io_completion gets set to HVMIO_pio_completion. We should then return true 
from handle_pio() resulting in RIP being advanced when we return to guest, but 
we should not get back into the guest because hvm_do_resume() should see the 
pending IO flag on one of the ioreq server vcpus and block on the relevant 
event channel.
So somehow it appears the vcpu got back into guest and executed the next 
instruction whilst there was pending I/O.

> 
> The exact port number of the earlier access isn't stable (above you see
> 3c4, but the other (debug) output had 3ce. These are the two ports
> stdvga.c intercepts without actually handling the accesses. The
> consistent part is that it's a VGA port write followed by a HPET read.
> 
> Yet in no event can I make any connection (yet) to our internal state
> getting screwed during a driver reload in a guest.
> 

No, I can't see any connection there at all.

  Paul

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