On 08/15/2011 09:21 AM, Daniel Veillard wrote:
On Sun, Aug 14, 2011 at 03:43:52AM -0400, Laine Stump wrote:
In some versions of qemu, both virtio-blk-pci and virtio-net-pci
devices can have an event_idx setting that determines some details of
event processing. When it is enabled, it "reduces the number of
interrupts and exits for the guest". qemu will automatically enable
this feature when it is available, but there may be cases where this
new feature could actually make performance worse (NB: no such case
has been found so far).
As a safety switch in case such a situation is encountered in the
field, this patch adds a new attribute "event_idx" to the<driver>
element of both disk and interface devices. event_idx can be set to
"on" (to force event_idx on in case qemu has it disabled by default)
or "off" (for force event_idx off). In the case that event_idx support
isn't present in qemu, the attribute is ignored (this on the advice of
the qemu developer).
This smells like an API available just as a safety belt for code
not fully tested in the field. So I have the same dislike for
consolidating this as a full long term libvirt API. But that's not
the first one, and I'm afraid it's not the last one, and it affects
only the XML domain with an extra attribute so the damage is limited.
[...]
+<li>
+ The optional<code>event_idx</code> attribute controls
+ some aspects of device event processing. The value can be
+ either 'on' or 'off' - if it is on, it will reduce the
+ number of interupts and exits for the guest. The default
+ is determined by QEMU; usually if the feature is
+ supported, default is on. In case there is a situation
+ where this behavior is suboptimal, this attribute provides
+ a way to force the feature off.
+<span class="since">Since 0.9.5 (QEMU and KVM only)</span>
+<b>In general you should leave this option alone, unless you
+ are very certain you know what you are doing.</b>
+</li>
Okay at least it's clear in the documentation
Code looks correct, there is one example trying to test both values
and for the 2 use cases, then fine,
ACK.
Thanks, I pushed it.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list