From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: VT-d spin loops Date: Wed, 23 Jul 2014 09:04:20 +0100 Message-ID: <53CF88A40200007800024F91@mail.emea.novell.com> References: <53A96B80020000780001CB8F@mail.emea.novell.com> <53AC124E020000780001D8FF@mail.emea.novell.com> <53AC124E020000780001D8FF@mail.emea.novell.com> <53BE62FB.2090105@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1X9rXD-0005na-SX for xen-devel@lists.xenproject.org; Wed, 23 Jul 2014 08:04:23 +0000 In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Yang Z Zhang Cc: Andrew Cooper , Malcolm Crossley , Kevin Tian , Donald D Dugger , xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 15.07.14 at 10:00, 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. Jan