[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 28.03.18 at 15:48, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 26 March 2018 09:43
>> 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 23.03.18 at 14:41, <Paul.Durrant@xxxxxxxxxx> wrote:
>> > So somehow it appears the vcpu got back into guest and executed the next
>> > instruction whilst there was pending I/O.
>> 
>> Two new pieces of information, in case either rings a bell:
>> 
> 
> Alas neither rings a bell.
> 
>> The issue appears to never occur in hap=0 mode.
>> 
> 
> That's quite an odd correlation.

Simply timing, perhaps. In any event, newest logs suggest we have
an issue with Windows paging out the page the data for the
REP OUTSW is coming from while the port I/O part of the operation
is pending qemu's completion. Upon retry the linear->physical
translation fails, and we leave incorrect state in place.

I thought we cache the translation result, thus avoiding the need
for a translation during the retry cycle, so either I'm misremembering
or this doesn't work as intended. And in fact doing the translation a
second time (with the potential of it failing) is wrong here - when the
port access has occurred, we must not fail the emulation anymore
(repeating the port write would probably be fine for the VGA, but
would hardly be fine for e.g. an IDE interface).

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.