On Tue, 15 Sep 2015 17:07:55 +0200 Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 15/09/2015 08:41, Jason Wang wrote: > > +With KVM_CAP_FAST_MMIO, a zero length mmio eventfd is allowed for > > +kernel to ignore the length of guest write and get a possible faster > > +response. Note the speedup may only work on some specific > > +architectures and setups. Otherwise, it's as fast as wildcard mmio > > +eventfd. > > I don't really like tying the capability to MMIO, especially since > zero length ioeventfd is already accepted for virtio-ccw. Actually, zero length ioeventfd does not make sense for virtio-ccw; we just don't check it (although we probably should). > > What about the following? > > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt > index 7a3cb48a644d..247944071cc8 100644 > --- a/Documentation/virtual/kvm/api.txt > +++ b/Documentation/virtual/kvm/api.txt > @@ -1627,11 +1627,10 @@ to the registered address is equal to datamatch in struct kvm_ioeventfd. > For virtio-ccw devices, addr contains the subchannel id and datamatch the > virtqueue index. > > -With KVM_CAP_FAST_MMIO, a zero length mmio eventfd is allowed for > -kernel to ignore the length of guest write and get a possible faster > -response. Note the speedup may only work on some specific > -architectures and setups. Otherwise, it's as fast as wildcard mmio > -eventfd. > +With KVM_CAP_IOEVENTFD_ANY_LENGTH, a zero length ioeventfd is allowed, and > +the kernel will ignore the length of guest write and get a faster vmexit. s/get/may get/ ? > +The speedup may only apply to specific architectures, but the ioeventfd will > +work anyway. -- 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
