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.
Can you elaborate? Which interfaces will need rework, and why?
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.
Yes, your patch on qemu-devel looks good. Even if we do have a
performance problem (which may well turn out after we optimize things
some more), it's easy to have a cached pointer along with the phys address.
--
error compiling committee.c: too many arguments to function
--
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
