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

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



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®.