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