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

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.