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
> >> --- a/hw/virtio
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
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_
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
---
hw/virtio/trace-events | 2 ++
hw/virtio
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
---
hw/virtio/virtio-rng.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/virti
On 03/30/2010 09:13 AM, Ian Molton wrote:
> From 5f484301d73fa53009bbcd430f8ae85868b67772 Mon Sep 17 00:00:00 2001
From: Ian Molton
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 charde
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 connect
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 daemo
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 connecti
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 dro
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 v
On 04/23/10 11:28, Ian Molton wrote:
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 se
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 suppo
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?)
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 pa
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 b
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
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
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
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
>
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
JustWork[tm]. No need for guest con
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 w
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 co
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
>
On 4/20/10, 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 mista
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 an
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 implementa
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
> 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 th
> 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
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 m
> 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 everyt
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
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 gue
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
>> >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-rn
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 wh
>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);
>From 5f484301d73fa53009bbcd430f8ae85868b67772 Mon Sep 17 00:00:00 2001
From: Ian Molton
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 either raw entropy or received
39 matches
Mail list logo
