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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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