Patch sent upstream:
https://www.redhat.com/archives/libvir-list/2011-April/msg01170.html

*) Describe in as much details as possible the requested feature?

 In the RHEL6.1 beta, KVM supports ioeventfd for virtio devices and the support is by default enabled 
 but it needs to be triggered by setting the property "ioeventfd=on|off" for the device parameter of the
 qemu-kvm command line, e.g.

    /usr/libexec/qemu-kvm -drive file=/dev/sda,id=drive-virtio-disk0 -device virtio-block-pci,ioeventfd=on,drive=drive-virtio-disk0 ...

 This RFE is regarding adding support to libvirt so that a VM managed by libvirt can have ioevenfd enabled|disabled for it's virtio devices.

*) Why is this feature important? What use-case will it enable? (List the business requirements here)

  This feature would allow to control the ioevenfd feature more easily allowing it to be enabled|disabled without tweaking the command line.
 
*) Functional requirements for the feature

 1) Support enabling of ioeventfd through the libvirt XML description of a VM.

*) For each functional requirement listed in question above, specify how to test to confirm the requirement is successfully implemented.

 1) Verify that a VM, for which ioeventfd has been enabled in it's libvirt XML description, indeed has been started 
    with the necessary command line that will enable ioeventfd for the specified drives. 

*) Is there already an existing RFE upstream or in Red Hat bugzilla?

  BZ #698340 is about the same feature

*) How quickly does this need resolved? What is the latest date when this needs to be available

 RHEL6.2 

*) Does this request meet the RHEL Inclusion criteria (please review)

 Yes it does

*) List the affected packages

 libvirt

*) Would the customer be able to assist in testing this functionality if implemented?

 Yes the customer is able assist in testing this functionality once it is implemented.

Moving to POST

commit 017abcbb1aa576a5f40d6bc8b905bbdacc5e4b94
Author: Michal Privoznik <mprivozn>
Date:   Mon Jun 20 10:26:47 2011 +0200

    qemu: domain I/O asynchronous handling
    
    For virtio disks and interfaces, qemu allows users to enable or disable
    ioeventfd feature. This means, qemu can execute domain code, while
    another thread waits for I/O event. Basically, in some cases it is win,
    in some loss. This feature is available via 'ioeventfd' attribute in disk
    and interface <driver> element. It accepts 'on' and 'off'. Leaving this
    attribute out defaults to hypervisor decision.

v0.9.2-153-g017abcb

Verified with following builds, which already been fixed.

libvirt-0.9.3-1.el6.x86_64
qemu-kvm-0.12.1.2-2.167.el6.x86_64

# virsh dumpxml test
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none' ioeventfd='on'/>
      <source file='/var/lib/libvirt/images/test.img'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05'
function='0x0'/>
    </disk>
...

# ps -ef | grep qemu-kvm
...
-drive
file=/var/lib/libvirt/images/test.img,if=none,id=drive-virtio-disk0,format=raw,cache=none
-device
virtio-blk-pci,ioeventfd=on,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
...

According to comment 7, move this to VERIFIED.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Casue: Libvirt was not supporting setting ioeventfd feature for virtio disks or interfaces. This feature allows QEMU to register some file descriptors and let kernel to wake it up from poll() instead of actively do polling. Thus, this reduce cpu usage

Consequence: QEMU has higher CPU usage

Change: Libvirt added support for setting this feature in VM definition XML

Result: Users can enable this feature in flavor of lower CPU usage

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1513.html