Anthony Liguori <anth...@codemonkey.ws> writes:
> On 06/20/2012 01:59 AM, Amit Shah wrote:
>> The Linux kernel already has a virtio-rng driver, this is the device
>> implementation.
>>
>> When the guest asks for entropy from the virtio hwrng, it puts a buffer
>> in the vq. We then put entropy into that buffer, and push it back to
>> the guest.
>>
>> The chardev connected to this device is fed the data to be sent to the
>> guest.
>>
>> Invocation is simple:
>>
>> $ qemu ... -device virtio-rng-pci,chardev=foo
>>
>> In the guest, we see
>>
>> $ cat /sys/devices/virtual/misc/hw_random/rng_available
>> virtio
>>
>> $ cat /sys/devices/virtual/misc/hw_random/rng_current
>> virtio
>>
>> # cat /dev/hwrng
>>
>> Simply feeding /dev/urandom from the host to the chardev is sufficient:
>>
>> $ qemu ... -chardev socket,path=/tmp/foo,server,nowait,id=foo \
>> -device virtio-rng,chardev=foo
>>
>> $ nc -U /tmp/foo< /dev/urandom
>>
>> A QMP event is sent for interested apps to monitor activity and send the
>> appropriate number of bytes that get asked by the guest:
>>
>> {"timestamp": {"seconds": 1337966878, "microseconds": 517009}, \
>> "event": "ENTROPY_NEEDED", "data": {"bytes": 64}}
>
> Nack.
>
> Use a protocol. This is not what QMP events are designed for!
>
> No human is going to launch nc to a unix domain socket to launch QEMU.
> That's a silly use-case to design for.
To be honest, I'm a bit surprised to see working code that got an ACK
from the guys with the problem it solves rejected out of hand over
something that feels like artistic license to me.
