|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [VTD][PATCH] Change xc_assign_device()
If don't consider hotplug case, do assignment in xend is no problem, but must guarantee that devices are hidden before assignment. Randy (Weidong) Keir Fraser wrote: > I think we're going round in circles now, but anyway: > > If you do all your checks in xend, then the setup in qemu-dm > shouldn't fail. > > If the setup in qemu-dm *does* fail then the domain should be shut > down. > > If the domain is shut down, the assignment will be torn down. > > So, why not leave the assignment in xend? > > -- Keir > > On 10/12/07 11:59, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote: > >> If the device has not been hidden by pciback, pciback will quit >> domain creation and prompt on screen. But current check we added in >> xenddomaininfo.py is executed before pciback check. >> >> Randy (Weidong) >> >> Keir Fraser wrote: >>> What if the device has not been hidden by pciback (a more likely >>> failure mode, I should think)? >>> >>> -- Keir >>> >>> On 10/12/07 11:41, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote: >>> >>>> The assignment is in qemu-dm originally, we moved it to xend for >>>> user friendly, because it can prompt user on screen. If strip it >>>> out, it is not easy for end user to find failure reason. >>>> >>>> Randy (Weidong) >>>> >>>> Keir Fraser wrote: >>>>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |