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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

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.

Jan


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