There's virtio-console, virtio-blk etc. None of these have kernel-modeIIUC, Ira already needs at least ethernet and console capability.
servers, but these could be implemented if/when needed.
No, what I mean is how do you surface multiple ethernet and consoles tob) what do you suppose this protocol to aggregate the connections wouldYou mean multilink? You expose the device as a multiqueue.
look like? (hint: this is what a vbus-connector does).
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 ;)
Ok, for kvm understood (and I would also add "qemu" to that mix). Butc) how do you manage the configuration, especially on a per-board basis?pci (for kvm/x86).
we are talking about vhost's application in a non-kvm environment here,
right?.
So if the vhost-X devices are in the "guest",
and the x86 board is just
a slave...How do you tell each ppc board how many devices and what
config (e.g. MACs, etc) to instantiate? Do you assume that they should
all be symmetric and based on positional (e.g. slot) data? What if you
want asymmetric configurations (if not here, perhaps in a different
environment)?
Yes. virtio is really virtualization oriented.I would say that its vhost in particular that is virtualization
oriented. virtio, as a concept, generally should work in physical
systems, if perhaps with some minor modifications. The biggest "limit"
is having "virt" in its name ;)