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
|
Home