[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [VTD][PATCH] Change xc_assign_device()



If the device has not been hidden by pciback, pciback will quit domain
creation and prompt on screen. But current check we added in
xenddomaininfo.py is executed before pciback check.

Randy (Weidong)

Keir Fraser wrote:
> What if the device has not been hidden by pciback (a more likely
> failure mode, I should think)?
> 
>  -- Keir
> 
> On 10/12/07 11:41, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
> 
>> The assignment is in qemu-dm originally, we moved it to xend for user
>> friendly, because it can prompt user on screen. If strip it out, it
>> is not easy for end user to find failure reason.
>> 
>> Randy (Weidong)
>> 
>> Keir Fraser wrote:
>>> The reason for moving device assignment to qemu-dm is that the
>>> assignment can fail even after the assignment has happened. I'm
>>> happy to move the assignment to qemu-dm, but then the 'check' in
>>> xend gets stripped out. 
>>> 
>>>  -- Keir
>>> 
>>> On 10/12/07 09:01, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
>>> 
>>>> The checks in Xend just check high level errors, such as VT-d
>>>> disabled, device is not exist, or not hidden. When find these
>>>> errors, quit domain creation immediately. The real actions are
>>>> taken in qemu. What error handling do you mean?
>>>> 
>>>> Randy (Weidong)
>>>> 
>>>> Keir Fraser wrote:
>>>>> Then the whole lot should be done in qemu-dm and it sounds like
>>>>> the error handling needs to be improved.
>>>>> 
>>>>>  -- Keir
>>>>> 
>>>>> On 10/12/07 08:45, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
>>>>> 
>>>>>> I agree the early do those checks the better. But without mapping
>>>>>> memory and I/O port in qemu, the assigned device can't be really
>>>>>> used. That's to say the assignment is not completed in a way. In
>>>>>> addition, if we want to support hotplug devices, it's not
>>>>>> suitable to do assignment in Xend. 
>>>>>> 
>>>>>> Randy (Weidong)
>>>>>> 
>>>>>> Keir Fraser wrote:
>>>>>>> Sounds to me like qemu-dm is too late to do those other checks
>>>>>>> or you need better error handling in qemu-dm. Really you have a
>>>>>>> choice: do all tests and assignment in qemu-dm, or do all tests
>>>>>>> and assignment in xend. Doing half-and-half is stupid. If the
>>>>>>> pass-through can still fail even after the check you leave in
>>>>>>> xend, why check at all in xend?
>>>>>>> 
>>>>>>> Probably you need to fail the domain create, or at least
>>>>>>> shutdown the domain, when a device that should be passed
>>>>>>> through cannot be passed through. That will naturally cause the
>>>>>>> device assignment to be torn down (if it was set set up), as
>>>>>>> the domain is destroyed. Whether this is all actioned from xend
>>>>>>> or from qemu-dm doesn't much matter, but the split
>>>>>>> responsibility isn't clean. Probably xend is better just
>>>>>>> because the error handling is easier and earlier there. 
>>>>>>> 
>>>>>>>  -- Keir
>>>>>>> 
>>>>>>> On 10/12/07 08:13, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
>>>>>>> 
>>>>>>>> Xend is too early to do real assignment, do some checking is
>>>>>>>> better. These two issues will be found by the checks in Xend (
>>>>>>>> 1) issue will be found by pciback). After passing these checks
>>>>>>>> in Xend, it's suitable to do real device assignment and memory
>>>>>>>> and ioport mappings in qemu. 
>>>>>>>> 
>>>>>>>> Randy (Weidong)
>>>>>>>> 
>>>>>>>> Muli Ben-Yehuda wrote:
>>>>>>>>> On Mon, Dec 10, 2007 at 02:21:55PM +0800, Han, Weidong wrote:
>>>>>>>>> 
>>>>>>>>>> Currently we assign devices with VT-d in Xend, this raises
>>>>>>>>>> two issues: 1) assign devices regardless of they are hidden
>>>>>>>>>> by pciback or not. If the device is not hidden, it results
>>>>>>>>>> in the device doesn't work in Dom0; 2) device is assigned
>>>>>>>>>> one by one, if assign multiple devices, some devices may
>>>>>>>>>> have been assigned when problem happens, it results in
>>>>>>>>>> assigned devices don't work in Dom0. I think Xend is not a
>>>>>>>>>> good place to assign devices. This patch adds a parameter to
>>>>>>>>>> xc_assign_device(), let it just do check in Xend whether the
>>>>>>>>>> devices can be assigned or not, and move real device
>>>>>>>>>> assignment to qemu. 
>>>>>>>>> 
>>>>>>>>> Why is qemu a better place to assign the devices? How does
>>>>>>>>> moving it to qemu solve the two issues mentioned above?
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Muli
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> Xen-devel mailing list
>>>>>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>>>>>> http://lists.xensource.com/xen-devel

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.