If kvm can do it, others can.The problem is that you seem to either hand-wave over details like this,
or you give details that are pretty much exactly what vbus does already.
My point is that I've already sat down and thought about these issues
and solved them in a freely available GPL'ed software package.
So the question is: is your position that vbus is all wrong and you wish
to create a new bus-like thing to solve the problem?
If so, how is it
different from what Ive already done? More importantly, what specific
objections do you have to what Ive done, as perhaps they can be fixed
instead of starting over?
There is no guest and host in this scenario. There's a device sideBingo. So now its a question of do you want to write this layer from
(ppc) and a driver side (x86). The driver side can access configuration
information on the device side. How to multiplex multiple devices is an
interesting exercise for whoever writes the virtio binding for that setup.
scratch, or re-use my framework.
No one said it was rocket science. But it does need to be designed andSounds trivial.I am talking about how we would tunnel the config space for N devices
across his transport.
implemented end-to-end, much of which Ive already done in what I hope is
an extensible way.
Write an address containing the device number andYou mean like the "u64 devh", and "u32 func" fields I have here for the
register number to on location, read or write data from another.
vbus-kvm connector?
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#l64
"Wrong" is probably too harsh a word when looking at ethernet. ItsThat sounds convenient given his hardware, but it has its own set ofWhy is it the wrong side?
problems. For one, the configuration/inventory of these boards is now
driven by the wrong side and has to be addressed.
certainly "odd", and possibly inconvenient. It would be like having
vhost in a KVM guest, and virtio-net running on the host. You could do
it, but its weird and awkward. Where it really falls apart and enters
the "wrong" category is for non-symmetric devices, like disk-io.
So if I have virtio-blk driver running on the x86 and vhost-blk deviceSecond, the roleThere is no role reversal.
reversal will likely not work for many models other than ethernet (e.g.
virtio-console or virtio-blk drivers running on the x86 board would be
naturally consuming services from the slave boards...virtio-net is an
exception because 802.x is generally symmetrical).
running on the ppc board, I can use the ppc board as a block-device.
What if I really wanted to go the other way?
The side doing dma is the device, the sideIIUC, his ppc boards really can be seen as "guests" (they are linux
accessing its own memory is the driver. Just like that other 1e12
driver/device pairs out there.
instances that are utilizing services from the x86, not the other way
around).
vhost forces the model to have the ppc boards act as IO-hosts,
whereas vbus would likely work in either direction due to its more
refined abstraction layer.
Of course vhost is incomplete, in the same sense that Linux isA vhost based solution to Iras design is missing more than userspace.
incomplete. Both require userspace.
Many of those gaps are addressed by a vbus based solution.