RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1509866 - Couldn't open event file when execute device_add for virtio-input-host-pci
Summary: Couldn't open event file when execute device_add for virtio-input-host-pci
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.5
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: Ján Tomko
QA Contact: jiyan
URL:
Whiteboard:
Depends On:
Blocks: 1379603
TreeView+ depends on / blocked
 
Reported: 2017-11-06 09:06 UTC by Han Han
Modified: 2018-04-10 11:00 UTC (History)
13 users (show)

Fixed In Version: libvirt-3.9.0-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 10:59:09 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0704 0 None None None 2018-04-10 11:00:18 UTC

Description Han Han 2017-11-06 09:06:39 UTC 
Description of problem:
As subject

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.10.0-4.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Start a VM
2. Prepare a input device, for example, plug a mouse to host
# cat /proc/bus/input/devices|tail -n 12
I: Bus=0003 Vendor=046d Product=c05a Version=0111
N: Name="Logitech USB Optical Mouse"
P: Phys=usb-0000:00:1a.0-1.3/input0
S: Sysfs=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input24
U: Uniq=
H: Handlers=mouse0 event2 
B: PROP=0
B: EV=17
B: KEY=70000 0 0 0 0
B: REL=103
B: MSC=10

# ls /dev/input/event2 -alZ
crw-rw----. root input system_u:object_r:event_device_t:s0 /dev/input/event2


3. Try to use device_add to attach the input device to VM:
# virsh qemu-monitor-command V-raw '{"execute":"device_add","arguments":{"driver":"virtio-input-host-pci","id":"input5","evdev":"/dev/input/event2","bus":"pci.0","addr":"0xe"}}'
{"id":"libvirt-28","error":{"class":"GenericError","desc":"Could not open '/dev/input/event2': No such file or directory"}}


Actual results:
As above

Expected results:
input device attached

Additional info:
Comment 2 Han Han 2017-11-06 09:11:16 UTC 
Block the test scenario of hotplug/hotunplug on virtio input passthrough devices in BZ1379603
Comment 3 Gerd Hoffmann 2017-11-06 12:32:48 UTC 
> 3. Try to use device_add to attach the input device to VM:
> # virsh qemu-monitor-command V-raw
> '{"execute":"device_add","arguments":{"driver":"virtio-input-host-pci","id":
> "input5","evdev":"/dev/input/event2","bus":"pci.0","addr":"0xe"}}'
> {"id":"libvirt-28","error":{"class":"GenericError","desc":"Could not open
> '/dev/input/event2': No such file or directory"}}

This is not going to work without proper libvirt support.  Libvirt must add /dev/input/event2 to the devices cgroup and adjust the svirt labels, simliar to how it is done for usb-host device files.  Otherwise qemu-kvm will not be allowed to access it.

So, in theory, when you use a libvirt build which has bug 1379603 fixed and you are using "virsh attach-device ..." instead of "virsh qemu-monitor-command" everything should work just fine.  Please retest.
Comment 4 Ján Tomko 2017-11-06 13:06:47 UTC 
If this is just about the libvirt use case, I forgot to add labelling and cgroup device whitelisting to the hotplug code path.

Unless this is reproducible with the same label as libvirt applies to the device on domain startup and with the evdev device listed in devices.allow (cgroup_device_acl in qemu.conf), I'd happily take the bug and move it to libvirt.
Comment 5 Gerd Hoffmann 2017-11-06 16:29:39 UTC 
(In reply to Ján Tomko from comment #4)
> If this is just about the libvirt use case, I forgot to add labelling and
> cgroup device whitelisting to the hotplug code path.

Well, at least report is about libvirt, and without labeling and cgroup whitelisting it has no chance to work.

> Unless this is reproducible with the same label as libvirt applies to the
> device on domain startup and with the evdev device listed in devices.allow
> (cgroup_device_acl in qemu.conf), I'd happily take the bug and move it to
> libvirt.

Done.
Comment 6 Han Han 2017-11-07 01:21:22 UTC 
(In reply to Gerd Hoffmann from comment #3)
> > 3. Try to use device_add to attach the input device to VM:
> > # virsh qemu-monitor-command V-raw
> > '{"execute":"device_add","arguments":{"driver":"virtio-input-host-pci","id":
> > "input5","evdev":"/dev/input/event2","bus":"pci.0","addr":"0xe"}}'
> > {"id":"libvirt-28","error":{"class":"GenericError","desc":"Could not open
> > '/dev/input/event2': No such file or directory"}}
> 
> This is not going to work without proper libvirt support.  Libvirt must add
> /dev/input/event2 to the devices cgroup and adjust the svirt labels, simliar
> to how it is done for usb-host device files.  Otherwise qemu-kvm will not be
> allowed to access it.
> 
> So, in theory, when you use a libvirt build which has bug 1379603 fixed and
> you are using "virsh attach-device ..." instead of "virsh
> qemu-monitor-command" everything should work just fine.  Please retest.

This bug also reproduced on libvirt-3.9.0-1.el7.x86_64 qemu-kvm-rhev-2.10.0-4.el7.x86_64

# cat /tmp/virtio-passthrough.xml
<input type='passthrough' bus='virtio'>
  <source evdev='/dev/input/event2'/>
</input>   

# virsh list 
 Id    Name                           State
----------------------------------------------------
 4     V                              running

# virsh attach-device V /tmp/virtio-passthrough.xml
error: Failed to attach device from /tmp/virtio-passthrough.xml
error: internal error: unable to execute QEMU command 'device_add': Could not open '/dev/input/event2': No such file or directory
Comment 7 Gerd Hoffmann 2017-11-07 07:05:02 UTC 
> > So, in theory, when you use a libvirt build which has bug 1379603 fixed and
> > you are using "virsh attach-device ..." instead of "virsh
> > qemu-monitor-command" everything should work just fine.  Please retest.
> 
> This bug also reproduced on libvirt-3.9.0-1.el7.x86_64
> qemu-kvm-rhev-2.10.0-4.el7.x86_64

Yes, as Jan wrote in comment 4 the libvirt patch is incomplete.
Comment 8 Ján Tomko 2017-11-21 15:06:27 UTC 
Upstream patches:
https://www.redhat.com/archives/libvir-list/2017-November/msg00821.html
Comment 11 jiyan 2017-12-04 09:28:26 UTC 
Hi, Ján.
When verifying this bug, it is found that attaching virtio input device will fail at the second time after restarting libvirtd service. Could you please check whether it is normal? thanks in advance.

The following are the detailed steps:

Test Components' Version
qemu-kvm-rhev-2.10.0-9.el7.x86_64
libvirt-3.9.0-4.el7.x86_64
kernel-3.10.0-799.el7.x86_64

Test Scenarios:
Step1. Prepare a VM running in the physical host with mouse input device plugged in, check the state of VM and info of input device
# virsh domstate pc
running

# virsh dumpxml pc |grep "<input type='passthrough' bus='virtio'>" -A4
No output

# cat /proc/bus/input/devices |grep "I: Bus=0003 Vendor=03f0 Product=094a Version=0111" -A11
I: Bus=0003 Vendor=03f0 Product=094a Version=0111
N: Name="PixArt HP USB Optical Mouse"
P: Phys=usb-0000:00:1a.0-1.4/input0
S: Sysfs=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input16
U: Uniq=
H: Handlers=mouse0 event9 
B: PROP=0
B: EV=17
B: KEY=ff0000 0 0 0 0
B: REL=103
B: MSC=10

# ll /dev/input/event9
crw-rw----. 1 root input 13, 73 Dec  4 17:18 /dev/input/event9

Step2. Prepare the following XML file used to hot-plug virtio input device to VM, then hot-plug and hot-unplug input device, during the process, check the VM dumpxml file 
# cat virtiomouse.xml 
<input type='passthrough' bus='virtio'>
  <source evdev='/dev/input/event9'/>
</input>   

# virsh attach-device pc virtiomouse.xml 
Device attached successfully

# virsh dumpxml pc |grep "<input type='passthrough' bus='virtio'>" -A4
    <input type='passthrough' bus='virtio'>
      <source evdev='/dev/input/event9'/>
      <alias name='input2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </input>

# virsh detach-device pc virtiomouse.xml 
Device detached successfully

# virsh dumpxml pc |grep "<input type='passthrough' bus='virtio'>" -A4
No output

Step3. Check the mouse input device again and restart libvirtd service
# cat /proc/bus/input/devices |grep "I: Bus=0003 Vendor=03f0 Product=094a Version=0111" -A11
I: Bus=0003 Vendor=03f0 Product=094a Version=0111
N: Name="PixArt HP USB Optical Mouse"
P: Phys=usb-0000:00:1a.0-1.4/input0
S: Sysfs=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input20
U: Uniq=
H: Handlers=mouse0 event9 
B: PROP=0
B: EV=17
B: KEY=ff0000 0 0 0 0
B: REL=103
B: MSC=10

# ll /dev/input/event9
crw-rw----. 1 root input 13, 73 Dec  4 17:18 /dev/input/event9

# systemctl restart libvirtd

# systemctl status libvirtd
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2017-12-04 17:20:52 CST; 5s ago

Step4. Hot-plug mouse input device again
# virsh attach-device pc virtiomouse.xml 
error: Failed to attach device from virtiomouse.xml
error: internal error: unable to execute QEMU command 'device_add': Bus 'pci' not found
Comment 12 Fangge Jin 2017-12-04 09:56:59 UTC 
Hi jiyan

Please see this bug for the "Bus 'pci' not found" issue:
Bug 1518148 - Fail to attach interface after libvirtd restart
Comment 13 jiyan 2017-12-06 07:48:05 UTC 
Test components' version
qemu-kvm-rhev-2.10.0-11.el7.x86_64
kernel-3.10.0-799.el7.x86_64
libvirt-3.9.0-5.el7.x86_64

Test scenarios
Preparation: Physical host with USB keyboard and mouse plugged in, and check 'event' info of them and prepare xml file according to the 'event' info
# cat /proc/bus/input/devices 
N: Name="Dell Dell USB Entry Keyboard"
P: Phys=usb-0000:00:1d.0-1.8/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.8/2-1.8:1.0/input/input2
H: Handlers=sysrq kbd leds event2 

# cat /proc/bus/input/devices 
N: Name="PixArt HP USB Optical Mouse"
P: Phys=usb-0000:00:1a.0-1.4/input0
S: Sysfs=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input14
H: Handlers=mouse0 event3 

# ll /dev/input/event2
crw-rw----. 1 root input 13, 66 Dec  6 14:48 /dev/input/event2

# ll /dev/input/event3
crw-rw----. 1 root input 13, 67 Dec  6 14:53 /dev/input/event3

# cat virtiokbd.xml 
<input type='passthrough' bus='virtio'>
  <source evdev='/dev/input/event2'/>
</input>   

# cat virtiomouse.xml 
<input type='passthrough' bus='virtio'>
  <source evdev='/dev/input/event3'/>
</input>   

Scenario1. Hot-plug/unplug virtio input device without restarting libvirtd service
Step1. Prepare a running VM
# virsh domstate pc
running

Step2. Hot-plug operation
# virsh attach-device pc virtiokbd.xml 
Device attached successfully

# virsh attach-device pc virtiomouse.xml 
Device attached successfully

# virsh dumpxml pc |grep passthrough -A4
    <input type='passthrough' bus='virtio'>
      <source evdev='/dev/input/event2'/>
      <alias name='input2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </input>
    <input type='passthrough' bus='virtio'>
      <source evdev='/dev/input/event3'/>
      <alias name='input3'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </input>

Step3. Hot-unplug operation
# virsh detach-device pc virtiokbd.xml 
Device detached successfully

# virsh detach-device pc virtiomouse.xml 
Device detached successfully

# virsh dumpxml pc |grep passthrough -A3
No output

Scenario2. Hot-plug/unplug virtio input device with restarting libvirtd service during the process
Step1. Prepare a running VM
# virsh domstate pc
running

Step2. Hot-plug operation
# virsh attach-device pc virtiokbd.xml 
Device attached successfully

# virsh attach-device pc virtiomouse.xml 
Device attached successfully

# virsh dumpxml pc |grep passthrough -A4
    <input type='passthrough' bus='virtio'>
      <source evdev='/dev/input/event2'/>
      <alias name='input2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </input>
    <input type='passthrough' bus='virtio'>
      <source evdev='/dev/input/event3'/>
      <alias name='input3'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </input>

Step3. Restart libvirtd and check the status of libvirtd
# systemctl restart libvirtd
# systemctl status libvirtd
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-12-06 15:38:57 CST; 6s ago

Step4. Hot-unplug operation
# virsh detach-device pc virtiokbd.xml 
Device detached successfully

# virsh detach-device pc virtiomouse.xml 
Device detached successfully

# virsh dumpxml pc |grep passthrough -A4
No output

Scenario3. Cold-plug/hot-unplug operation
Step1. Prepare a shutdown VM
# virsh domstate pc
shut off

Step2. Cold-plug operation
# virsh attach-device pc virtiokbd.xml --config
Device attached successfully

# virsh attach-device pc virtiomouse.xml --config
Device attached successfully

# virsh dumpxml pc --inactive |grep passthrough -A4
    <input type='passthrough' bus='virtio'>
      <source evdev='/dev/input/event2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </input>
    <input type='passthrough' bus='virtio'>
      <source evdev='/dev/input/event3'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </input>

Step3. Start VM then check dumpxml file and qemu cmd line
# virsh start pc
Domain pc started

# virsh dumpxml pc |grep passthrough -A4
    <input type='passthrough' bus='virtio'>
      <source evdev='/dev/input/event2'/>
      <alias name='input2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </input>
    <input type='passthrough' bus='virtio'>
      <source evdev='/dev/input/event3'/>
      <alias name='input3'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </input>

# ps -ef |grep pc | sed 's/-device/\n-device/g'
-device virtio-input-host-pci,id=input2,evdev=/dev/input/event2,bus=pci.0,addr=0xa 
-device virtio-input-host-pci,id=input3,evdev=/dev/input/event3,bus=pci.0,addr=0xb

Step4. Hot-unplug operation
# virsh detach-device pc virtiokbd.xml 
Device detached successfully

# virsh detach-device pc virtiomouse.xml 
Device detached successfully

# virsh dumpxml pc |grep passthrough -A4
No output

All the results are as expected, move this bug to be verified.
Comment 17 errata-xmlrpc 2018-04-10 10:59:09 UTC 
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.

https://access.redhat.com/errata/RHEA-2018:0704
Note You need to log in before you can comment on or make changes to this bug.