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