Re: VT-d device assignment may fail (regression from Xen c/s 19805:2f1fa2215e60)

[Weidong Han <weidong.han@intel.com>]

Jan Beulich wrote:
>>>> On 27.10.10 at 07:43, Weidong Han <weidong.han@intel.com> 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
>>> <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.
>   
Agree!

Regards,
Weidong