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

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



If don't consider hotplug case, do assignment in xend is no problem, but
must guarantee that devices are hidden before assignment.

Randy (Weidong)

Keir Fraser wrote:
> I think we're going round in circles now, but anyway:
>
> If you do all your checks in xend, then the setup in qemu-dm
> shouldn't fail. 
> 
> If the setup in qemu-dm *does* fail then the domain should be shut
> down. 
> 
> If the domain is shut down, the assignment will be torn down.
> 
> So, why not leave the assignment in xend?
> 
>  -- Keir
> 
> On 10/12/07 11:59, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
> 
>> 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

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