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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.03.18 at 16:20, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----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?

I've sent him a patch simply suppressing the registration of the PIO
intercept function, but my XTF code doesn't behave any different
with that. I should say though that (without knowing yet whether
that's also the case on that Windows version) my code does the
REP OUTSW from video memory, which causes the string operation
to be split independent of what stdvga.c does (see the bottom of
hvmemul_rep_outs()). Without doing that, I hadn't been able to
observe anything unusual at all, i.e. none of the dozen or so
printk()s I had added ever triggered.

Jan


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