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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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