virtual device bus "xen bus"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "RvR" == Rik van Riel <riel@xxxxxxxxxx> writes:
>>>>> "DB" == David Boutcher <boutcher@xxxxxxxxxx> writes:
>>>>> "JK" == Jeremy Katz <katzj@xxxxxxxxxx> 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




[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux