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

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


  • To: 'Jan Beulich' <JBeulich@xxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Thu, 29 Mar 2018 08:42:41 +0000
  • Accept-language: en-GB, en-US
  • Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 29 Mar 2018 08:43:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHTxN6G4rdc2h08Vk6fEESsSx3T0aPloZcwgAAOlACAACdo0IAAyysAgABFiLA=
  • Thread-topic: possible I/O emulation state machine issue

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 29 March 2018 07:27
> 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 18:22, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 28 March 2018 16:59
> >>
> >> 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).
> >
> > Yes, I thought we made sure all reps were completed using cached
> > translations before returning to guest.
> 
> We do this only for actual MMIO accesses, not for RAM ones,
> afaics.
> 
> I think I see a way to deal with the specific case here, but we'll
> certainly need to make things work properly in the general case.
> That's not something reasonable to be done for 4.11 though.
> 

Page table modification racing with an emulation sounds pretty bad though. I 
guess that if the damage is only limited to the guest though it's not something 
that requires immediate fix.

> Suppressing the stdvga port intercepts has, btw, not helped the
> situation.
> 

That surprises me. The whole string emulation should go out to QEMU without 
being broken up in that case, and since it's an outsw I don't see why there 
would be any retry of the linear->physical translation during completion.

  Paul

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