Avi Kivity wrote:
Anthony Liguori wrote:
Why not merge these bits prior to merging virtio? They aren't kvm
specific and would be good in mainline qemu.
I'd rather have a consumer of an interface before merging the actual
infrastructure.
So merge them all into qemu at the same time (as separate patches, if
you like).
But that will require refactoring a lot of these optimizations. In
order to do that right, they need to be presented on qemu-devel. It's a
whole lot easier to do that incrementally so that people can digest it
all instead of blasting a big series.
I've posted virtio before on the qemu-devel and what has always been
problematic are the various optimizations we do. They tend to cloud the
actual implementation of virtio. I think taking this approach will make
it all a lot easier.
The amount of code duplication is frightening.
I've already got that worked out. I need to prepare and commit a patch
to fix stw/lduw in upstream QEMU and then we can switch to always using
those functions in KVM. I've done some performance testing and that
seems to be enough. With that, there is no longer any scary code
duplication.
Oh, and we need to set the dirty bit so live migration works. Or do we
have a hack in place to force copying of the ring at the last stage?
With the above fix, the rings accesses are no longer an issue. We just
need to dirty memory in the scatter/gather lists on write. That's a
very simple change and I'll include it in the next patch series.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
