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.
Thanks,
--
Yuji Shimada
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home