[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [VTD][PATCH] Change xc_assign_device()
On Mon, Dec 10, 2007 at 09:00:49AM +0000, Keir Fraser wrote: > Then the whole lot should be done in qemu-dm and it sounds like the error > handling needs to be improved. Can we figure out a better way for communication between qemu-dm and Xend? After creation, qemu-dm is detached from Xend without any tools to notify Xend. Maybe, Xend can poll the xenstore for qemu-dm device assignment success? > > -- 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 > -- best rgds, edwin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |