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 917886 - reading hwrng device in guest, can not fetch the data from host
Summary: reading hwrng device in guest, can not fetch the data from host
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: Amit Shah
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: VirtIORNG
TreeView+ depends on / blocked
 
Reported: 2013-03-05 02:45 UTC by yunpingzheng
Modified: 2014-03-04 00:13 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-17 11:02:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description yunpingzheng 2013-03-05 02:45:44 UTC
Description of problem:
when i boot a guest(rhel6.4) with rng device, open the hwrng device in guest ,can not fetch the data form host. in guest the virtio-rng driver have loaded , the hwrng is available and using by kernel.

Version-Release number of selected component (if applicable):
kernel: kernel-3.7.0-0.34.el7.x86_64
qemu: qemu-kvm-1.3.0-5.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.[Host] boot guest with rng device like :
   -device virtio-rng-pci
2.[guest] check the driver virtio-rng have been loaded.
   #lsmod | grep rng
3.[guest] check the rng device in availble in guest
   $ cat /sys/devices/virtual/misc/hw_random/rng_available
4.[guest] Check is the current hwrng device in use by the kernel:
   $ cat /sys/devices/virtual/misc/hw_random/rng_current
5.[guest] Open rng device to fetch data from host (wait several minutes, do some op in host, like move the mice).
   #cat /dev/hwrng
 
 
Actual results:
   in step 2 ,3 ,4 we can see the drive have been loaded. the hwrng device is available and is using by the kernel. but in step5 "cat /dev/hwrng" have no output. 

Expected results:
 in step 5 should have some output.

Additional info:
qemu-command:
/usr/libexec/qemu-kvm \
-name 'vm1' \
-nodefaults \
-m 4096 \
-smp 4,cores=2,threads=1,sockets=2 \
-vnc :22 \
-vga qxl \
-rtc base=utc,clock=host,driftfix=none \
-drive file=/root/RHEL-Server-6.4-64-virtio.qcow2,if=none,cache=none,id=virtio0 \
-device virtio-blk-pci,drive=virtio0 \
-device virtio-net-pci,netdev=id3Ibo2c,mac=9a:5e:5f:60:61:62 \
-netdev tap,id=id3Ibo2c,script=/root/qemu-ifup-switch \
-device ich9-usb-uhci1,id=usb1 \
-boot order=cdn,once=c,menu=on \
-enable-kvm \
-monitor stdio \
-global PIIX4_PM.disable_s3=0 \
-global PIIX4_PM.disable_s4=0 \
-chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/qmpmonitor-1,server,nowait \
-mon chardev=qmp_id_qmpmonitor1,mode=control \
-chardev socket,id=isa-serial-1,path=/tmp/isa-serial-1,server,nowait \
-device isa-serial,chardev=isa-serial-1 \
-device virtio-serial,id=virt-serial-1,max_ports=31,bus=pci.0 \
-chardev socket,id=virtio-serial-1-1,path=/tmp/virtio-serial-1-1,server,nowait \
-device virtserialport,chardev=virtio-serial-1-1,name=virtio.serial.1.1,bus=virt-serial-1.0,id=virtio-serial-port1-1 \
-device virtio-serial,id=virt-console-1 \
-chardev socket,id=virtio-console-1-1,path=/tmp/virtio-console-1-1,server,nowait \
-device virtconsole,chardev=virtio-console-1-1,name=virtio.console.1.1,bus=virt-console-1.0 \
-device virtio-rng-pci

host cpuinfo:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 42
Stepping:              7
CPU MHz:               1600.000
BogoMIPS:              6784.61
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7

Comment 2 Amit Shah 2013-04-16 10:43:35 UTC
Instead of using 'cat' on the guest, use something like the following:

python
import os
f = os.open('/dev/hwrng', os.O_RDONLY)
os.read(f, 1)

and then you can read more bytes, like

os.read(f, 10)

or even in a loop:

while 1:
    os.read(f, 10)


If the read returns with data, that means things are working fine.  Relying on 'cat' means displayable characters are returned by the host all the time, which may not be true.

Comment 3 yunpingzheng 2013-04-17 06:25:37 UTC
hi Amit

using python read it works. you mean the characters are always not displayable ?

os.open("/dev/hwrng", os.O_RDONLY)
4
>>> os.read(4, 10)
'h\xca\x8b\xeb5\x96r\xb7A\x7f'
>>> while 1:
...     os.read(4,10)
... 
'\x16c\xab\x0b\x8b\xc5\xca\xd1\x95\xa9'

',\x06\x8dy\x95\xa9\xc5\xdb,\x06'

'\x95\xa9\xc5\xdb,\x06\x8dy\x95\xa9'
',\x06\x8dy\x95\xa9\xc5\xdb,\x06'
'\x95\xa9\xc5\xdb,\x06\x8dy\x95\xa9'

Comment 4 Amit Shah 2013-04-17 11:02:45 UTC
So looks like everything works, and I'll close this bug.


Note You need to log in before you can comment on or make changes to this bug.