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

On Tue, Apr 11, 2017 at 07:42:02PM +0200, Laurent Vivier wrote: > 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 > >> ---

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

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 @@

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

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,

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

If we modify the virtio-rng virqueue while the vmstate is already migrated we can have some inconsistencies between the virtqueue state and the memory content. To avoid this, stop the virtqueue while the CPU is stopped. Signed-off-by: Laurent Vivier ---

[Qemu-devel] [PATCH 2/2] virtio-rng: replace error_set calls with error_setg

Under recommendation from Luiz Capitulino, we are changing the error_set calls to error_setg while we are fixing up the error handling pathways of virtio-rng. Signed-off-by: John Snow js...@redhat.com --- hw/virtio/virtio-rng.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

On 03/30/2010 09:13 AM, Ian Molton wrote: From 5f484301d73fa53009bbcd430f8ae85868b67772 Mon Sep 17 00:00:00 2001 From: Ian Moltonian.mol...@collabora.co.uk Date: Tue, 17 Nov 2009 14:34:12 + Subject: [PATCH 2/4] virtio: Add virtio-rng driver This patch adds support for virtio-rng.

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

On 24/04/10 02:37, Jamie Lokier wrote: Ian Molton wrote: Jamie Lokier wrote: First of all: Why are your egd daemons with open connections dying anyway? Buggy egd? No, they aren't buggy. but occasionally, the sysadmin of said server farms may want to, you know, update the daemon? Many

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

On 23/04/10 18:32, Jamie Lokier wrote: Ian Molton wrote: You can configure any chardev to be a tcp client. I never do that though as I find it much more convenient to configure it as server. Perhaps thats because chardev clients are nearly useless right now because they just die if the

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Ian Molton wrote: Jamie Lokier wrote: First of all: Why are your egd daemons with open connections dying anyway? Buggy egd? No, they aren't buggy. but occasionally, the sysadmin of said server farms may want to, you know, update the daemon? Many daemons don't kill active connections on

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Hi, Im not sure I agree there... surely there are other things which would benefit from generic socket reconnection support (virtio-rng cant be the only driver that might want to rely on a reliable source of data via a socket in a server-farm type situation?) Usually qemu takes the server

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Gerd Hoffmann wrote: Hi, Im not sure I agree there... surely there are other things which would benefit from generic socket reconnection support (virtio-rng cant be the only driver that might want to rely on a reliable source of data via a socket in a server-farm type situation?)

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Jamie Lokier wrote: Ian Molton wrote: It might make sense to have the reconnect logic in the egd chardev backend then, thereby obsoleting the socket reconnect patch. Im not sure I agree there... surely there are other things which would benefit from generic socket reconnection support

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

On 23/04/10 15:07, Gerd Hoffmann wrote: In my usage of qemu I didn't came across a use case which needs qemu reconnecting yet. You're comparing apples with oranges :-) IMHO I don't. Well, comparing a connection where qemu is the server to one where it is the client doesn't seem terribly

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Ian Molton wrote: You can configure any chardev to be a tcp client. I never do that though as I find it much more convenient to configure it as server. Perhaps thats because chardev clients are nearly useless right now because they just die if the connection drops... Which is why

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Gerd Hoffmann wrote: Hi, * the SIZE property patch:Msg-Id:4bb206b9.80...@collabora.co.uk Fine with me. \o/ So should I re-post that patch, or can I count on that being folded into mainline ? * the socket reconnect patch: Msg-Id:4b18055b.1030...@collabora.co.uk Not sure yet.

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Ian Molton wrote: It might make sense to have the reconnect logic in the egd chardev backend then, thereby obsoleting the socket reconnect patch. Im not sure I agree there... surely there are other things which would benefit from generic socket reconnection support (virtio-rng cant be the

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Gerd Hoffmann wrote: On 04/20/10 23:31, Ian Molton wrote: Using virtio-rng means that the data is going into the guest kernels hwrng subsystem. Which is *the* major advantage of the virtio-rng driver. In case the guest kernel is recent enougth to have support for it, it will

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Jamie Lokier wrote: But enough of that: It's history now; the guest virtio-rng has existed for more than a year. It is also amazingly short and simple. Yay for Rusty! Ok, so... If we can now take steps to integrate the code... I'd like to get some feedback (or merging!) of the other parts

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Hi, * the SIZE property patch:Msg-Id:4bb206b9.80...@collabora.co.uk Fine with me. * the socket reconnect patch: Msg-Id:4b18055b.1030...@collabora.co.uk Not sure yet. If we can get these patches sorted out, the only outstanding issues are where the EGD protocol support and rate

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Paul Brook wrote: So, rather than bike-shedding, how about making some kind of decision? Ok, let me make this simple. Great! Features such as rate limiting and EGD protocol translation should not be part of individual device emulation. They are part of the host interface, not the

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Ian Molton wrote: One last and quite important point - where should the EGD protocol implementation go? really it needs to work as kind-of a line discipline, but AFAICT thats not supported? it would be a mistake to put rate limiting in the chardev layer and leave the EGD protocol

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Jamie Lokier wrote: Hi :-) Ian Molton wrote: One last and quite important point - where should the EGD protocol implementation go? really it needs to work as kind-of a line discipline, but AFAICT thats not supported? it would be a mistake to put rate limiting in the chardev layer and leave

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

On 4/20/10, Ian Molton ian.mol...@collabora.co.uk wrote: Jamie Lokier wrote: Hi :-) Ian Molton wrote: One last and quite important point - where should the EGD protocol implementation go? really it needs to work as kind-of a line discipline, but AFAICT thats not supported? it

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Ian Molton wrote: Jamie Lokier wrote: Hi :-) Ian Molton wrote: One last and quite important point - where should the EGD protocol implementation go? really it needs to work as kind-of a line discipline, but AFAICT thats not supported? it would be a mistake to put rate limiting in

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Jamie Lokier wrote: Ian Molton wrote: Jamie Lokier wrote: What do the other hypervisors supporting virtio-rng do? Um. support it? Im not sure what you mean there. Do the other hypervisors do anything special to support EGD, or is it just treated as another kind of serial port connected to

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Ian Molton wrote: I've merely implemented one solution in qemu that other hypervisors *AND* the kernel already support, and that users want. I think that's a good reason to include virtio-rng support in some form. I suspect Paul's objection may have been due to an impression that virtio-rng

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Paul Brook wrote: Paul Brook wrote: So now everything that looks like a stream of bytes has to use the virtio-serial code... IMO, yes. That's the whole point of virtio-serial. You can handle it however you like in your in your favourite guest OS, but I object to qemu having multiple

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Bear in mind that its rather unfair to (as has been in this case) have a patch reviewed, modified based on criticism, and then rejected after effort has been wasted working on it. I'm pretty sure I raised all these issues the first time this code was submitted. Paul

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

So, rather than bike-shedding, how about making some kind of decision? Ok, let me make this simple. Features such as rate limiting and EGD protocol translation should not be part of individual device emulation. They are part of the host interface, not the guest machine. If you really want

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Paul Brook wrote: This patch adds support for virtio-rng. Data is read from a chardev and can be either raw entropy or received via the EGD protocol. I still don't get why you need this at all. It seems like virtio-serial would already provides everything you need. I guess

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Paul Brook wrote: This patch adds support for virtio-rng. Data is read from a chardev and can be either raw entropy or received via the EGD protocol. I still don't get why you need this at all. It seems like virtio-serial would already provides everything you need. Because we need

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Paul Brook wrote: This patch adds support for virtio-rng. Data is read from a chardev and can be either raw entropy or received via the EGD protocol. I still don't get why you need this at all. It seems like virtio-serial would already provides everything you need. I guess when

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Jamie Lokier wrote: I would hope that the host can rate limit itself without needing apps to govern themselves, though. That depends on the source of the entropy - some sources can, some are fed to daemons that can, but not all systems have such daemons. :) -Ian

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

This patch adds support for virtio-rng. Data is read from a chardev and can be either raw entropy or received via the EGD protocol. I still don't get why you need this at all. It seems like virtio-serial would already provides everything you need. +qemu_gettimeofday(now);

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

Paul Brook wrote: This patch adds support for virtio-rng. Data is read from a chardev and can be either raw entropy or received via the EGD protocol. I still don't get why you need this at all. It seems like virtio-serial would already provides everything you need. I guess when

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

This patch adds support for virtio-rng. Data is read from a chardev and can be either raw entropy or received via the EGD protocol. I still don't get why you need this at all. It seems like virtio-serial would already provides everything you need. I guess when virtio-rng was first

Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG

From 5f484301d73fa53009bbcd430f8ae85868b67772 Mon Sep 17 00:00:00 2001 From: Ian Molton ian.mol...@collabora.co.uk Date: Tue, 17 Nov 2009 14:34:12 + Subject: [PATCH 2/4] virtio: Add virtio-rng driver This patch adds support for virtio-rng. Data is read from a chardev and can be