>>>>> "RvR" == Rik van Riel <riel@redhat.com>
writes:
>>>>> "DB" == David Boutcher
<boutcher@us.ibm.com> writes:
>>>>> "JK" == Jeremy Katz <katzj@redhat.com>
writes:
RvR> If anybody here has virtual bus code that they would like
RvR> to see reused in Xen, please follow up to this mail so we
RvR> can get things started soon.
DB> I would hate to see a xen virtual bus...I would love to see
DB> the power5 VIO bus move out of arch/ppc64 and into somewhere
DB> generic.
We at TJ Watson have demonstrated that the Power5 VIO bus can be ported
to work with non-OF data structures, the correct abstractions should
be able to easily move from a VMM specific data structure to some
cannonical Linux form.
We have two phases where this canonical struct is important:
1. Boot-time discovery:
- PPC recieves an OF device tree rooted at /vdevice
- x86 recieves a wad of stuff that describes the bus and its
devices.
2. Runtime discovery:
- in this case both PPc and x86 would get this information from
the hotplug daemon or something else.
I'd like to propose that we create a hotplug bus type for VIO and
use the resulting data structures as the conanonical form.
JK> Well, "xen virtual bus" meaning here "a virtual bus being
used by
JK> xen". VIO isn't insane to think about (in fact, I've
looked
JK> quite a bit at it since I'm familiar with the power5 stuff :),
JK> but as it stands right now, the VIO stuff is fairly ugly (imho)
JK> since the entire file is basically
I believe Xen is planning on using the the hotplug services as well.
I think perhpas we want to explor a simple, designed for logical PNP,
event mechanism. Way simpler than BIOS, perhaps almost IPC in nature
where the datastructure we are going to use for x86 is formalized.
However, I do not know how Xen communicates these things.
Off the top of my head:
struct vio_data {
u32 type; /* NIC, Disk, Socket, Block, etc.. */
u32 irq; /* unique interrupt source */
/* each device gets its own logical bus and unique IO-TLB */
u32 logical_bus_number;
/* Identifier, device specific xform of the lbn. */
u32 id;
/* size of IO-TLB if any */
size_t dma_range;
size_t size; /* of this data structure */
char data[0];
}
datais for device specific data, example:
NIC: Default ether addr
Socket: Default IP addr
Block: Type?
Disk: lable?
Much of the above is based on our experience. If it makes sense out
of context (of vhype) then lets move this discussion public. Having
vHype released can at least point to some code, that uses these
properties.
-JX