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

Re: [Xen-devel] VT-d spin loops



> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Wednesday, July 23, 2014 1:04 AM
> 
> >>> On 15.07.14 at 10:00, <yang.z.zhang@xxxxxxxxx> wrote:
> > Andrew Cooper wrote on 2014-07-10:
> >> On 10/07/14 00:22, Tian, Kevin wrote:
> >>> ATS should be fine. Device TLB can ONLY be validated through qinval
> >>> interface, which is asynchronous so no need to consider 1 minute
> >>> timeout even in current spinning model.
> >>
> >> There are currently no asynchronous invalidations in Xen. ATS
> >> certainly is a problem.
> >
> > How Linux upstream handle ATS? Does it have any asynchronous
> invalidations
> > mechanism?
> 
> Not according to my inspection of the code.
> 
> >>> In general yes a non-spinning model is better, but it requires
> >>> non-trivial change to make all IOMMU operations asynchronous. If ATS
> >>> is not a concern, is it still worthy of change besides auditing existing
> > usages?
> >>
> >> Even if the invalidation is only at the IOMMU, waiting milliseconds
> >> for the completion is still time better spent elsewhere, such as running
> > VMs.
> >>
> >> Do you have any numbers for typical completion times for invalidate
> > requests?
> >>
> >
> > The invalidations are completed fairly quickly by hardware. So the cost for
> > spin can be ignored?
> 
> No, we have to be prepared for a timeout to occur, without killing
> the entire host (killing the guest owning affected device would be
> acceptable as a consequence), even more so with the longer
> timeouts mandated by ATS.
> 

right. for ATS we really need an asynchronous implementation, while 
doing that also means whole spin loop concept is changed.


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