>ron minnich wrote:
>> Let me ask what may seem to be a naive question to the linux world. I
>> see you are doing a lot off solid work on adding block and network
>> devices. The code for block and network devices
>> is implemented in different ways. I've also seen this difference of
>> inerface/implementation on Xen.
>Actually, the difference derives from the fact that block and network
>are indeed different:
>- block submits requests that ask the host to transfer from/to
>preallocated guest data buffers via dma (request driven)
>- net transmits packets that should end up in an skb on the remote
>side (two way, push driven)
>- net is sensitive to round-trip times, block is not due to the device
>plug for request merging
>
>We tried different access methods for both block and network. We have
>selected the current communication mechanics after doing performance
>measurements.
>I believe for a portable solution we need to develop a set of
>primitives for sending signals (read: interrupts) back and forth, for
>copying data to guest memory, and for establishing shared memory
>between guests and between guest+host. These primitives need to be
>implemented for each platform, and paravirtual drivers should build on
>top of that.
>At this point in time, we are aware that these device drivers don't do
>what we'd want for a portable solution. We'll focus on getting the
>kernel interfaces to sie/vt/svm proper and portable first.
>
>so long,
>Carsten
Based on the previous discussion and the s390 PV drivers I have more
gasoline to pour to the flame:
We have a working PV driver with 1Gbit performance. The reasons we don't
push it into the kernel are:
a. We should perform much better
b. It would be a painful task getting all the code review that a
complicated network interface should get.
c. There's already a PV driver that answers a,b.
The Xen's PV network driver is now pushed into the kernel.
It is optimized, and support tso.
By adding a generic ops calls we can make enjoy all the above.
Using Xen's core PV code doesn't imply that we will have their interface
{xenstore} the interface creation and tear-down would be kvm specific.
They could even have a plain directory structure.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
