From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weidong Han Subject: Re: VT-d device assignment may fail (regression from Xen c/s 19805:2f1fa2215e60) Date: Thu, 28 Oct 2010 08:26:27 +0800 Message-ID: <4CC8C333.50805@intel.com> References: <4CC17FE5020000780001E91F@vpn.id2.novell.com> <4CC7BBFC.8010802@intel.com> <4CC8133C020000780001F6A5@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4CC8133C020000780001F6A5@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "Jiang, Yunhong" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org Jan Beulich wrote: >>>> On 27.10.10 at 07:43, Weidong Han wrote: >>>> >> Jan Beulich wrote: >> >>> need some additional consideration, since from looking at the code >>> I would say that reassign_device_ownership() needs some error >>> handling improvements too: Currently, partial failure isn't being >>> handled properly at all (respective devices are left in a half way >>> state - no longer properly assigned to Dom0, but also not yet >>> assigned to DomU). >>> >>> >> Agree. The assignment should guarantee "done" or "none". >> > > Are you going to work on this? > Not yet. I'm working on other priority tasks. > >>> I also wonder what guarantee there is for a device to exist at >>> :00.0 (since if there is none, the same context_present() >>> check could at least theoretically again lead to problems as it >>> checks for pci_get_pdev() returning non-NULL >>> >>> Finally, isn't it inconsistent that only the original device gets its >>> ->domain set to the new owner and gets moved to that domain's >>> device list, but neither the upstream bridge nor that bridge's >>> :00.0 get handled the same way? What if below that >>> >>> >> Yes, it's better to do the same for the upstream bridge. >> > > And this? > > >>> bridge a device gets hot-added? Wouldn't that device >>> incorrectly end up in Dom0, with no failures because the bridge >>> still appears to be owned by Dom0 while it really isn't? >>> >>> >> Do you want some error message for this case? >> > > First of all I'd want the case to be handled correctly. Only if it > really can't be handled, I'd want an error message, yes, as > silent failure leading to later mysterious misbehavior is very > hard to diagnose. > Agree! Regards, Weidong