On Thu, Mar 05, 2009 at 05:15:18PM +0900, Yuji Shimada wrote:
> On Thu, 5 Mar 2009 16:12:10 +1100
> Simon Horman <horms@xxxxxxxxxxxx> wrote:
> > I think that your idea sounds very reasonable, especially since it is
> > backwards-compatible.
> >
> > Looking at your diagram, where the SBDF of PNP0A08:0-3.0-2.0 changes from
> > 0000:02:02.0 to 0000:03:02.0, I wonder if there are any places where this
> > change could cause problems in existing xen, ioemu-dm or xend code.
> >
> > * I wonder what would happen if PNP0A08:0-3.0-2.0 was hot-plugged into a
> > domU as 0000:02:02.0 and subsequently an attempt to hot-unplug it from
> > the same domU.
> >
> > * I wonder what would happen if PNP0A08:0-3.0-2.0 was hidden from
> > dom0 at boot time by referring to it as 0000:02:02.0 and then
> > after its SBDF had changed to 0000:03:02.0 an attempt was made
> > to hot-plug or otherwise pass-through the device to a domU.
>
> Hi Simon,
>
> First of all, change of SBDF in my diagram does not show example of
> runtime hotplug. If linux is booted in the situation of left side
> diagram, hotplug of PCI-PCI bridge[4.0] and device[0.0] fails.
> Because, linux does not rebalance bus# at runtime, and there is no
> free bus# under PCI-PCI bridge[1.0].
> My diagram shows example of inserting bridge and device while machine
> is power off.
>
> One of reasons using device path is for "xm new" command and "xm start"
> command.
> When guest is prepared by "xm new", xend stores guest information
> including device path in a disk. And when the guest starts by "xm
> start", stored guest information is used. The guest information remains
> even if hypervisor is rebooted. When we use SBDF, the different device
> will be assigned if SBDF is changed at boot time.
> When we use device path, the same device will be assigned even if SBDF
> is changed at boot time.
> So, unchanging device path is reasonable.
Hi Shimada-san,
thanks for the clarification, my problems were assuming
that physical hot-plug was occuring. As you point out,
that is not the case so the issues I suggested can't occur.
--
Simon Horman
VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home