On Wed, Jul 30, 2014 at 11:25 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 30/07/2014 17:12, Michael S. Tsirkin ha scritto: >>> > >>> > Dataplane must not be a change to the guest ABI. If you implement this >>> > feature you have to implement it for both dataplane and non-dataplne. >>> >
IMO, no matter if the feature is set or not, both old and new VM can support it well. Per virtio spec, only the feature is set, the VM can be allowed to access the 'num_queues' field, and I didn't see any problem from VM's view point. So could you explain why both dataplane and non-dataplane have to support the feature. I am doing so because there isn't performance advantage to take mq for non-dataplane. >>> > Paolo >> Actually, I think different backends at runtime should be allowed to >> change guest visible ABI. For example if you give qemu a read only >> backend this is guest visible right? > > Dataplane is not meant to be a different backend, it's just moving stuff > out to a separate thread. It's only due to QEMU limitation that it > doesn't share the vring code (and these patches include a lot of steps > backwards where dataplane becomes != non-dataplane). There won't lots of backwards steps, just the bypass co patch, which is just bypassing co in case of being unnecessary for raw image case, but it is still one code path. As I mentioned, all these steps are just for the performance regression from the commit 580b6b2aa2(dataplane: use the QEMU block layer for I/O). Thanks,
