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/
Home Products Support Community News


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

To: "Weidong Han" <weidong.han@xxxxxxxxx>
Subject: [Xen-devel] Re: VT-d device assignment may fail (regression from Xen c/s 19805:2f1fa2215e60)
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 27 Oct 2010 10:55:40 +0100
Cc: Yunhong Jiang <yunhong.jiang@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 27 Oct 2010 02:56:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CC7BBFC.8010802@xxxxxxxxx>
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>
References: <4CC17FE5020000780001E91F@xxxxxxxxxxxxxxxxxx> <4CC7BBFC.8010802@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 27.10.10 at 07:43, Weidong Han <weidong.han@xxxxxxxxx> 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?

>> 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
> 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.


Xen-devel mailing list