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

Re: [Xen-devel] Revisit VT-d asynchronous flush issue



> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> Sent: Monday, November 02, 2015 7:40 PM
> 
> >
> > Based on above information, we propose to continue spin-timeout
> > model w/ some adjustment, which fixes current timeout concern
> > and also allows limited ATS support in a light way:
> >
> > 1) reduce spin timeout to 1ms, which can be boot-time changed
> > up to 10ms.
> 
> If this is going to be command line configurable, don't have an upper limit.
> 
> Given the uncertainty with external devices, it might be necessary to
> experiment with timeouts greater than 10ms.

That also works.

> 
> >
> > 2) if timeout expires, kill the VM which the target device is assigned
> > to. Optionally hypervisor may mark device non-assignable.
> >
> > It works for devices w/o ATS. It works for integrated devices w/ ATS.
> > It might or might not work for discrete devices w/ ATS, but we can
> > re-evaluate the gain vs. software complexity of async flush until we
> > see many discrete devices breaking the timeout assumptions in the
> > future.
> >
> > Thoughts?
> 
> As presented, this is probably an improvement, but I am concerning with
> the case of external devices.
> 
> Then again, as none of this currently works at all, we are not in a
> worse state.
> 

Understood. So based on your and Jan's comments, let's go with
this proposal first.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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