qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/2] virtio-rng: stop virtqueue while the CPU is


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH 2/2] virtio-rng: stop virtqueue while the CPU is stopped
Date: Tue, 11 Apr 2017 19:42:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 11/04/2017 19:02, Stefan Hajnoczi wrote:
> On Tue, Apr 11, 2017 at 03:17:33PM +0200, Laurent Vivier wrote:
>> diff --git a/hw/virtio/virtio-rng.c b/hw/virtio/virtio-rng.c
>> index 9639f4e..d270d56 100644
>> --- a/hw/virtio/virtio-rng.c
>> +++ b/hw/virtio/virtio-rng.c
>> @@ -53,6 +53,15 @@ static void chr_read(void *opaque, const void *buf, 
>> size_t size)
>>          return;
>>      }
>>  
>> +    /* we can't modify the virtqueue until
>> +     * our state is fully synced
>> +     */
>> +
>> +    if (!runstate_check(RUN_STATE_RUNNING)) {
>> +        trace_virtio_rng_cpu_is_stopped(vrng);
>> +        return;
>> +    }
>> +
> 
> I'm concerned about what happens when the guest is stopped and resumed
> (e.g. 'stop' and 'cont' monitor commands).  Since we throw away the
> chr_read() callback the device will hang unless the guest kicks it
> again?
> 
> It's not clear to me that the rate limit timer will help us...

I think you're right (even if it seems hard to generate this case)

What is the best solution:

- re-arming the timer/the backend request by calling
virtio_rng_process() before the "return;"

or

- adding a vmstate change handler to call virtio_rng_process()?

Thanks,
Laurent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]