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

[Xen-devel] VT-d device assignment may fail (regression from Xen c/s 198

To: "Weidong Han" <weidong.han@xxxxxxxxx>
Subject: [Xen-devel] VT-d device assignment may fail (regression from Xen c/s 19805:2f1fa2215e60)
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 22 Oct 2010 11:13:25 +0100
Cc: yunhong.jiang@xxxxxxxxx, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 22 Oct 2010 03:14:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
Weidong,

in this patch you removed a bus/devfn check around an invocation of
domain_context_mapping_one() avoiding the attempt to call the
function again if it was already called for this very device. This
removal, however, conflicts with the context_present() check at the
top of domain_context_mapping_one() - in particular, pdev->domain
isn't set to the new owner yet, and hence the function fails.

The question now is whether some similar check should be restored,
or whether pdev->domain should get updated earlier. This may
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).

I also wonder what guarantee there is for a device to exist at
<secbus>: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
<secbus>:00.0 get handled the same way? What if below that
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?

Jan


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