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