On Fri, Feb 27, 2009 at 01:53:32PM +0900, Yuji Shimada wrote:
> On Thu, 26 Feb 2009 10:00:30 +0000
> David Edmondson <dme@xxxxxxx> wrote:
>
> >
> > On 26 Feb 2009, at 8:40am, Yuji Shimada wrote:
> > > I hope developers give me some comments.
> >
> > I don't really have an opinion about what happens on Linux.
> >
> > The current Solaris IO domain work uses the BDF derived naming for PCI
> > devices in domain specifications. We have been discussing using
> > Solaris device paths (such as /pci@0,0/pci8086,3605@2/pci8086,3500@0/
> > pci8086,3518@2/pci108e,4836@0,1) instead, as it would simplify various
> > parts of our implementation and administration model.
Hi David,
is there a situation in Solaris where the BDF can change,
like the situation that Shimada-san has described in Linux?
> Thank you for your reply.
>
> I'm sorry, I don't know much about Solaris device path.
> My device path doesn't use bus# but ACPI's _HID, _UID, device# and
> function#. Therefore, even if a new device is added, device path
> remains unchanged. For your reference, I attached our example figure.
>
> My device path is similar to EFI's one. So my RFC suits fine on x86 and
> IA64 architecture.
>
> My RFC keeps current Xen's SBDF assignment. So you can add Solaris
> device path if you need to do.
Hi Shimada-san,
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.
--
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