On 09/24/2009 10:27 PM, Ira W. Snyder wrote:
Ira can make ira-bus, and ira-eventfd, etc, etc.
Each iteration will invariably introduce duplicated parts of the stack.
Invariably? Use libraries (virtio-shmem.ko, libvhost.so).
Referencing libraries that don't yet exist doesn't seem like a good
argument against vbus from my point of view. I'm not speficially
advocating for vbus; I'm just letting you know how it looks to another
developer in the trenches.
My argument is that we shouldn't write a new framework instead of fixing
or extending an existing one.
If you'd like to see the amount of duplication present, look at the code
I'm currently working on.
Yes, virtio-phys-guest looks pretty much duplicated. Looks like it
should be pretty easy to deduplicate.
It mostly works at this point, though I
haven't finished my userspace, nor figured out how to actually transfer
data.
The current question I have (just to let you know where I am in
development) is:
I have the physical address of the remote data, but how do I get it into
a userspace buffer, so I can pass it to tun?
vhost does guest physical address to host userspace address (it your
scenario, remote physical to local virtual) using a table of memory
slots; there's an ioctl that allows userspace to initialize that table.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
