WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] RE: [PATCH] [RFC] VT-d: always clean up dpci timers.

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] RE: [PATCH] [RFC] VT-d: always clean up dpci timers.
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Mon, 25 Jul 2011 15:47:59 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>
Delivery-date: Mon, 25 Jul 2011 07:49:00 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=u1QmVXS/JQsLqQwrxwvF1IZPwX2rAIdTnDpkw7fc6io=; b=uhrLT+epGB/gF+FXBaSm0zmj725bNQYiXFPoEXI8HyjAphXwO5qvYbZ6eiKJagmZCs qoQziRZsmcTdfPcGaWhtorGp7Mmt/Vap+ZkTqMyX/uUGzVQkLJGHYv9cwUSh0wQJ+CRH vK+V/UapvB/0PiL2UREUX8fva3jnbZjNM2uR8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110725142120.GD8970@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcxK2dilQmMG3gUKt0CEurzIZYbImA==
Thread-topic: [Xen-devel] RE: [PATCH] [RFC] VT-d: always clean up dpci timers.
User-agent: Microsoft-Entourage/12.30.0.110427
On 25/07/2011 15:21, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx> wrote:

>> Could we make need_iommu(d) sticky? Being able to clear it doesn't seem an
>> important case (such a domain is probably being torn down anyway) and
>> clearly it can lead to fragility. The fact that presumably we'd end up doing
>> unnecessary IOMMU PT work for the remaining lifetime of the domain doesn't
>> seem a major downside to me.
> 
> If you prefer it that way.  TBH I think I prefer the other way though:
> things that gate on need_iommu() should be cleaned up by
> iommu->teardown().

Is your original patch still proposed as a valid alternative to this one?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel