* Alexander Graf <agraf@xxxxxxx> wrote:
>
> On 04.06.2011, at 16:46, Ingo Molnar wrote:
>
> >
> > * Alexander Graf <agraf@xxxxxxx> wrote:
> >
> >> So the simple rule is: don't register a coalesced MMIO region for a
> >> region where latency matters. [...]
> >
> > So my first suspicion is confirmed.
> >
> > A quick look at Qemu sources shows that lots of drivers are using
> > coalesced_mmio without being aware of the latency effects and only
> > one seems to make use of qemu_flush_coalesced_mmio_buffer(). Drivers
> > like hw/e1000.c sure look latency critical to me.
>
> e1000 maps its NVRAM on coalesced mmio - which is completely ok.
Ok!
> > So i maintain my initial opinion: this is a pretty dangerous
> > 'optimization' that should be used with extreme care: i can tell
> > it you with pretty good authority that latency problems are much
> > more easy to introduce than to find and remove ...
>
> Yup, which is why it's very sparsely used in qemu :). Basically,
> it's only e1000 and vga, both of which are heavily used and tested
> drivers.
Ok, so this change in:
commit 73389b5ea017288a949ae27536c8cfd298d3e317
Author: Sasha Levin <levinsasha928@xxxxxxxxx>
Date: Fri Jun 3 22:51:08 2011 +0300
kvm tools: Add MMIO coalescing support
@@ -67,6 +70,16 @@ bool kvm__register_mmio(u64 phys_addr, u64 phys_addr_len, void (*kvm_mmio_callba
.kvm_mmio_callback_fn = kvm_mmio_callback_fn,
};
+ zone = (struct kvm_coalesced_mmio_zone) {
+ .addr = phys_addr,
+ .size = phys_addr_len,
+ };
+ ret = ioctl(kvm->vm_fd, KVM_REGISTER_COALESCED_MMIO, &zone);
+ if (ret < 0) {
+ free(mmio);
+ return false;
+ }
Seems completely wrong, because it indiscriminately registers *all*
mmio regions as coalesced ones.
Thanks,
Ingo
--
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
