Amit Shah <amit.s...@redhat.com> writes:
> On (Mon) 01 Apr 2013 [09:02:46], Anthony Liguori wrote:
>> Amit Shah <amit.s...@redhat.com> writes:
>>
>> > Opening backends in non-blocking mode isn't necessary, we don't do
>> > anything while waiting for data.
>> >
>> > This also excuses us from checking for EAGAIN, which for the default
>> > random backend, is a very common return error type.
>>
>> It's not common... It really shouldn't happen however.
>
> EAGAIN is common when a file is opened in non-blocking mode. Needs to
> be made verbose?
EAGAIN doesn't just happen randomly. It only happens when you read from
an fd when no data is present. Normally, that is something that is
predictable.
>> > Starting the guest
>> > with '-device virtio-rng-pci', issuing a 'cat /dev/hwrng' in the guest
>> > while also doing 'cat /dev/random' on the host causes
>>
>> You are essentially cat'ing the same device twice. What's happening is
>> that there is entropy available in /dev/random so a select()
>> notification happens but before we are able to read() it, the cat of
>> /dev/hwrng ends up consuming that entropy.
>>
>> This would never happen with a socket, for instance. /dev/random is
>> special in there are multiple readers.
>>
>> >
>> > backends/rng-random.c:44:entropy_available: assertion failed: (len != -1)
>> >
>> > without this fix.
>>
>> This fix would cause QEMU to block indefinitely which I don't think is
>> very good behavior. I think a better solution would be:
>>
>> diff --git a/backends/rng-random.c b/backends/rng-random.c
>> index acd20af..9fde566 100644
>> --- a/backends/rng-random.c
>> +++ b/backends/rng-random.c
>> @@ -41,6 +41,9 @@ static void entropy_available(void *opaque)
>> ssize_t len;
>>
>> len = read(s->fd, buffer, s->size);
>> + if (len == -1 && errno == EINTR) {
>> + return;
>> + }
That's a typo. I meant s/EINTR/EAGAIN/g
Regards,
Anthony Liguori
>
> This has to be an additional fix on top of this one. EAGAIN has to be
> handled if we want to allow nonblocking reads, and there doesn't seem
> to be any reason to have these reads be non-blocking.
>
> OTOH, I also think we could use the glib functions for file IO, since
> handling EINTR in each open-coded read call isn't always fun.
>
> Amit
