Paul Brook wrote:
Actually according to qemu's standard, one should use cpu_physical_memory_write/ cpu_physical_memory_read functions. This is true also for reading the ring values.Yes, and unfortunately, cpu_physical_memory_{read,write} are copy interfaces. We really don't want that for high speed I/O.I really don't like doing direct access to guest ram without implementing a proper API for zero-copy/scatter-gather access. There was a list thread about this not so long ago.
I agree that we need a proper API for sg ram access. I'm going to look into that real soon since it's necessary to optimize the network/disk transports.
virtio makes things a bit trickier though. There's a shared ring queue between the host and guest. The ring queue is lock-less and depends on the ability to atomically increment ring queue indices to be SMP safe. Using a copy-API wouldn't be a problem for QEMU since the host and guest are always running in lock-step. A copy API is actually needed to deal with differing host/guest alignment and endianness.
Once you introduce KVM though, this is no longer true since KVM supports true SMP. The solution may be to implement some sort of atomic_increment function and then have that use a if (kvm) guard to do a direct access verses a copy.
Regards, Anthony Liguori
Paul
