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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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