On 01/17/2011 02:48 PM, Marcelo Tosatti wrote:
On Mon, Jan 17, 2011 at 02:18:43PM +0200, Avi Kivity wrote: > On 01/17/2011 02:18 PM, Sheng Yang wrote: > >> > + > >> > + if (copy_to_user((void __user *)(entry_base + offset), val, len)) > >> > + goto out; > >> > >> Instead of copying to/from userspace (which is subject to swapin, > >> unexpected values), you could include the guest written value in a > >> kvm_run structure, along with address. Qemu-kvm would use that to > >> synchronize its copy of the table, on KVM_EXIT_MSIX_ROUTING_UPDATE exit. > > > >We want to acelerate MSI-X mask bit accessing, which won't exit to userspace in > >the most condition. That's the cost we want to optimize. Also it's possible to > >userspace to read the correct value of MMIO(but mostly userspace can't write to it > >in order to prevent synchronize issue). > > It's also good to have the values in just one place; using userspace > makes it easy for both the kernel and userspace to see the values > (and set them after migration, if/when we extend this to virtio). Right, thats an advantage, but: - How can userspace ever synchronize with updates by the kernel to the MSI-X entry?
What a value is written by the guest, which kvm cannot handle itself (i.e. a change to anything other than the mask bit), we exit with the table and entry ids, so userspace can reread them.
- Reading/writing to the userspace area must be done carefully, values must be validated before used.
True every time...
- Swapping issue (minor?).
I don't see the issue... just like any part of qemu that may be swapped out, blocking the vcpu thread.
-- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
