[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |