[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |