Michael S. Tsirkin wrote: > On Tue, Sep 15, 2009 at 05:39:27PM -0400, Gregory Haskins wrote: >> Michael S. Tsirkin wrote: >>> On Tue, Sep 15, 2009 at 04:43:58PM -0400, Gregory Haskins wrote: >>>> Michael S. Tsirkin wrote: >>>>> On Tue, Sep 15, 2009 at 04:08:23PM -0400, Gregory Haskins wrote: >>>>>> No, what I mean is how do you surface multiple ethernet and consoles to >>>>>> the guests? For Ira's case, I think he needs at minimum at least one of >>>>>> each, and he mentioned possibly having two unique ethernets at one point. >>>>>> >>>>>> His slave boards surface themselves as PCI devices to the x86 >>>>>> host. So how do you use that to make multiple vhost-based devices (say >>>>>> two virtio-nets, and a virtio-console) communicate across the transport? >>>>>> >>>>>> There are multiple ways to do this, but what I am saying is that >>>>>> whatever is conceived will start to look eerily like a vbus-connector, >>>>>> since this is one of its primary purposes ;) >>>>> Can't all this be in userspace? >>>> Can you outline your proposal? >>>> >>>> -Greg >>>> >>> Userspace in x86 maps a PCI region, uses it for communication with ppc? >>> >> And what do you propose this communication to look like? > > Who cares? Implement vbus protocol there if you like. > Exactly. My point is that you need something like a vbus protocol there. ;) Here is the protocol I run over PCI in AlacrityVM: http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=blob;f=include/linux/vbus_pci.h;h=fe337590e644017392e4c9d9236150adb2333729;hb=ded8ce2005a85c174ba93ee26f8d67049ef11025 And I guess to your point, yes the protocol can technically be in userspace (outside of whatever you need for the in-kernel portion of the communication transport, if any. The vbus-connector design does not specify where the protocol needs to take place, per se. Note, however, for performance reasons some parts of the protocol may want to be in the kernel (such as DEVCALL and SHMSIGNAL). It is for this reason that I just run all of it there, because IMO its simpler than splitting it up. The slow path stuff just rides on infrastructure that I need for fast-path anyway, so it doesn't really cost me anything additional. Kind Regards, -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
