Re: [Qemu-devel] Socket reconnection.
Jamie Lokier wrote: Ian Molton wrote: Besides, not all entropy comes from /dev/random. Those arguments are weak. No worse than the counterarguments. If nothing else, qemu is a useful tool for testing kernel subsystems and in fact the virtio code triggered and caused to be fixed a number of bugs / flaws in the kernels hw random core and virtio driver. That alone I think shows it has value. I grant you there are advantages sometimes, but also disadvantages. Why would I run egd on a guest VM running an embedded system with 16MB RAM, where every process is precious, for example? But those systems need entropy too. I have no idea - too much crack? :-) one might run rngd, or use /dev/hwrng directly, but I cant see why you'd want to run egd on it. As for why feed it directly via hardware - egd - guest, the reason surely is because most clients read /dev/random or /dev/urandom, so entropy that isn't injected into /dev/random is wasted. Im not proposing that. I'm saying the HOST machine would be getting entropy from egd, directly into qemu. That entropy comes out of the guests /dev/hwrng. I can see value there too - the hosts /dev/random pool cannot be compromised by the guest OS. But nothings stopping you specifying /dev/random as qemus entropy source. But the main issue is below. On all host systems I have access to, there is _no_ entropy available from egd/rngd... I have no system here with that hardware either - however I had access (via an ssh tunnel) to another machine that did have it, and could feed qemu direct from that stream. qemu spoke egd over the tunnel, and fed the guests /dev/hwrng. The guest was passing FIPS tests at the same speed the hardware could produce entropy. Are you suggesting that I should have fed the hosts entropy pool (via RNGD) and then fed that to the guest ia qemu? why? Since we need this on hosts without /dev/random anyway, I dont see why we would need to deliberately cripple qemu on linux hosts... The lack of option is crippling qemu on linux hosts which don't run egd. Sorry, what? Which hosts are those? Well, I've just checked five live systems, four servers and one laptop, running: Ubuntu 9.10 (Karmic) - no egd running, no rngd running Ubuntu 9.04 (Jaunty) - no egd running, no rngd running Debian 4.0 (Etch) - no egd running, no rngd running apt-get install rng-tools CentOS 4.0- no egd running, no rngd running RHEL 4.0 - no egd running, no rngd running Presumably one can install rngd easily on these systems too. I have a machine here that is not running X - does that make X worthless? So if I understand right, the virtio-rng host driver won't work on any host system I have access to? Is that correct? No, because it is just as happy reading raw data from /dev/random as it it to speak EGD protocol over a socket. Have you actually tried the patch? -Ian
Re: [Qemu-devel] Socket reconnection.
Ian Molton wrote: Jamie Lokier wrote: I'm a bit puzzled. Why isn't virtio-rng getting entropy from /dev/random on the host? /dev/random may not be available. Understood on a non-Linux host. Besides, not all entropy comes from /dev/random. On a Linux host, why isn't rngd simply injecting it's entropy into /dev/random where it would be more convenient to access? (No need for socket reconnection code, for example). -- Jamie
Re: [Qemu-devel] Socket reconnection.
Jamie Lokier wrote: Ian Molton wrote: Jamie Lokier wrote: I'm a bit puzzled. Why isn't virtio-rng getting entropy from /dev/random on the host? /dev/random may not be available. Understood on a non-Linux host. Or a linux host with a user with insufficient privs... Besides, not all entropy comes from /dev/random. On a Linux host, why isn't rngd simply injecting it's entropy into /dev/random where it would be more convenient to access? (No need for socket reconnection code, for example). Who knows? lack of privs, an admin who only uses egd, a machine which is being fed entropy by egd via a tunnel. User doesnt trust /dev/random, /dev/random known to be failing FIPS tests on a shared machine - there could be any number of reasons. In our case, entropy is comming from hardware via egd, to be used in the guest VMs. why feed it into RNGD, then the hosts entropy pool, THEN the guests - just feed them directly. the egd daemon in this case also offers load balancing to all consumers of entropy. Since we need this on hosts without /dev/random anyway, I dont see why we would need to deliberately cripple qemu on linux hosts... -Ian
Re: [Qemu-devel] Socket reconnection.
Ian Molton wrote: Besides, not all entropy comes from /dev/random. On a Linux host, why isn't rngd simply injecting it's entropy into /dev/random where it would be more convenient to access? (No need for socket reconnection code, for example). Who knows? lack of privs, an admin who only uses egd, a machine which is being fed entropy by egd via a tunnel. User doesnt trust /dev/random, /dev/random known to be failing FIPS tests on a shared machine - there could be any number of reasons. In our case, entropy is comming from hardware via egd, to be used in the guest VMs. why feed it into RNGD, then the hosts entropy pool, THEN the guests - just feed them directly. the egd daemon in this case also offers load balancing to all consumers of entropy. Those arguments are weak because they also apply the other way: an admin who only uses /dev/random (got lots of those), a machine which is being fed entropy into /dev/random via a tunnel (been there), user doesn't trust egd (why should I trust it more than the kernel? userspace is more easily corrupted - and with a socket, it might not even be egd running), etc. I grant you there are advantages sometimes, but also disadvantages. Why would I run egd on a guest VM running an embedded system with 16MB RAM, where every process is precious, for example? But those systems need entropy too. As for why feed it directly via hardware - egd - guest, the reason surely is because most clients read /dev/random or /dev/urandom, so entropy that isn't injected into /dev/random is wasted. Anyway, I've just read the rngd manual, and it does inject it's entropy into /dev/random so that's the end of that discussion :-) But the main issue is below. On all host systems I have access to, there is _no_ entropy available from egd/rngd... Since we need this on hosts without /dev/random anyway, I dont see why we would need to deliberately cripple qemu on linux hosts... Since nobody has asked you to cripple anything, that is irrelevant. Options don't cripple. The lack of option is crippling qemu on linux hosts which don't run egd. Which hosts are those? Well, I've just checked five live systems, four servers and one laptop, running: Ubuntu 9.10 (Karmic) - no egd running, no rngd running Ubuntu 9.04 (Jaunty) - no egd running, no rngd running Debian 4.0 (Etch) - no egd running, no rngd running CentOS 4.0- no egd running, no rngd running RHEL 4.0 - no egd running, no rngd running So if I understand right, the virtio-rng host driver won't work on any host system I have access to? Is that correct? Btw, /dev/random is available on virtually every host - Linux, Solaris, FreeBSD, Mac OS X, NetBSD, OpenBSD, Tru64, HP-UX, AIX, and there's even a similar device for Windows :-) I grant you the egd/rngd entropy is preferable on a system that's running it. It is much more careful. (Let's ignore this in rngd's man page: Do not do that unless you trust rngd's source of random data). So a good default would be to use the egd/rngd socket when available, and fall back to /dev/random or even /dev/urandom (at user request) when not. My tests show that egd/rngd are not running on any host system I have access to - and that's quite a diverse range of Linuxes. It would have to be run specially, which sounds problematic as qemu would be the only process using it. -- Jamie
Re: [Qemu-devel] Socket reconnection.
Krumme, Chris wrote:
Hello Ian,
Hello!
Qemu_malloc will never return 0, so sched function can return void.
Gah! nasty. Check removed.
This is a mixture of tabs and spaces, for new code pick one.
I've been sticking with spaces generally. I can't find 'CodingStyle' so
I copied. I think spaces suck for this though. What is acceptable?
linux kernel style ?
The if(prev) can just be this = prev; if prev is NULL you want NULL
anyway.
Quite. Fixed.
Thanks
Likewise.
Fresh patch attached. Anthony, if this is ok, I can rebase this and its
prerequisite.
From 05581c5badd693b7537fe57f85a2ff5ddcb7972d Mon Sep 17 00:00:00 2001
From: Ian Molton ian.mol...@collabora.co.uk
Date: Tue, 1 Dec 2009 11:18:41 +
Subject: [PATCH 2/4] socket: Add a reconnect option.
Add a reconnect option that allows sockets to reconnect (after a
specified delay) to the specified server. This makes the virtio-rng driver
useful in production environments where the EGD server may need to be restarted.
Signed-off-by: Ian Molton ian.mol...@collabora.co.uk
---
qemu-char.c | 169 -
qemu-char.h |2 +
qemu-config.c |3 +
vl.c |4 ++
4 files changed, 139 insertions(+), 39 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index e202585..f20d697 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1870,8 +1870,12 @@ typedef struct {
int max_size;
int do_telnetopt;
int do_nodelay;
+int reconnect;
int is_unix;
int msgfd;
+QemuOpts *opts;
+CharDriverState *chr;
+int (*setup)(QemuOpts *opts);
} TCPCharDriver;
static void tcp_chr_accept(void *opaque);
@@ -2011,6 +2015,61 @@ static ssize_t tcp_chr_recv(CharDriverState *chr, char
*buf, size_t len)
}
#endif
+struct reconnect_list {
+TCPCharDriver *s;
+uint64_t when;
+struct reconnect_list *next;
+};
+
+static struct reconnect_list *rc_list;
+
+static void qemu_chr_sched_reconnect(TCPCharDriver *s)
+{
+struct reconnect_list *new = qemu_malloc(sizeof(*new));
+struct timeval tv;
+
+gettimeofday(tv, NULL);
+new-s = s;
+new-when = (s-reconnect + tv.tv_sec) * 100 + tv.tv_usec;
+new-next = rc_list;
+rc_list = new;
+}
+
+static int qemu_chr_connect_socket(TCPCharDriver *s);
+
+void qemu_chr_reconnect(void)
+{
+struct reconnect_list *this = rc_list, *prev = NULL;
+struct timeval tv;
+uint64_t now;
+
+if (!this)
+return;
+
+gettimeofday(tv, NULL);
+now = tv.tv_sec * 100 + tv.tv_usec;
+
+while (this) {
+if (this-when = now) {
+if (qemu_chr_connect_socket(this-s)) {
+if (prev)
+prev-next = this-next;
+else
+rc_list = NULL;
+qemu_chr_event(this-s-chr, CHR_EVENT_RECONNECTED);
+free(this);
+this = prev;
+}
+else {
+this-when += this-s-reconnect * 100;
+}
+}
+prev = this;
+ if (this)
+this = this-next;
+}
+}
+
static void tcp_chr_read(void *opaque)
{
CharDriverState *chr = opaque;
@@ -2030,10 +2089,16 @@ static void tcp_chr_read(void *opaque)
if (s-listen_fd = 0) {
qemu_set_fd_handler(s-listen_fd, tcp_chr_accept, NULL, chr);
}
-qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+if (!s-reconnect) {
+qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+}
closesocket(s-fd);
s-fd = -1;
-qemu_chr_event(chr, CHR_EVENT_CLOSED);
+if (s-reconnect) {
+qemu_chr_sched_reconnect(s);
+} else {
+qemu_chr_event(chr, CHR_EVENT_CLOSED);
+}
} else if (size 0) {
if (s-do_telnetopt)
tcp_chr_process_IAC_bytes(chr, s, buf, size);
@@ -2137,7 +2202,6 @@ static CharDriverState *qemu_chr_open_socket(QemuOpts
*opts)
{
CharDriverState *chr = NULL;
TCPCharDriver *s = NULL;
-int fd = -1;
int is_listen;
int is_waitconnect;
int do_nodelay;
@@ -2145,34 +2209,40 @@ static CharDriverState *qemu_chr_open_socket(QemuOpts
*opts)
int is_telnet;
is_listen = qemu_opt_get_bool(opts, server, 0);
+is_unix= qemu_opt_get(opts, path) != NULL;
+
is_waitconnect = qemu_opt_get_bool(opts, wait, 1);
is_telnet = qemu_opt_get_bool(opts, telnet, 0);
do_nodelay = !qemu_opt_get_bool(opts, delay, 1);
-is_unix= qemu_opt_get(opts, path) != NULL;
-if (!is_listen)
+
+if (!is_listen) {
is_waitconnect = 0;
+} else {
+if (is_telnet)
+s-do_telnetopt = 1;
+}
+
-chr = qemu_mallocz(sizeof(CharDriverState));
s = qemu_mallocz(sizeof(TCPCharDriver));
+chr = qemu_mallocz(sizeof(CharDriverState));
+s-opts = opts;
+
+if (!is_listen !is_telnet)
+s-reconnect = qemu_opt_get_number(opts, reconnect, 0);
Re: [Qemu-devel] Socket reconnection.
Am 03.12.2009 11:04, schrieb Ian Molton: Krumme, Chris wrote: This is a mixture of tabs and spaces, for new code pick one. I've been sticking with spaces generally. I can't find 'CodingStyle' so I copied. I think spaces suck for this though. What is acceptable? linux kernel style ? Four spaces. The file is called CODING_STYLE and it's in the top level directory. Kevin
Re: [Qemu-devel] Socket reconnection.
Anthony Liguori wrote:
sleep() in qemu is very, very wrong. It will pause the guest's
execution and all sorts of badness can ensue.
Quite...
The right thing to do is set a timer and not generate data while
disconnected.
New patch attached, now with less crack...
I still am not confident this is really a great thing to do.
What other option is there than to drop the ability to feed entropy to
the guest when the hosts egd link drops?
btw. Does anyone know how to get t-bird to inline patches?
-Ian
From e9d4be9cd0ef9e34c65939d4604874035c45bf34 Mon Sep 17 00:00:00 2001
From: Ian Molton ian.mol...@collabora.co.uk
Date: Tue, 1 Dec 2009 11:18:41 +
Subject: [PATCH 2/4] socket: Add a reconnect option.
Add a reconnect option that allows sockets to reconnect (after a
specified delay) to the specified server. This makes the virtio-rng driver
useful in production environments where the EGD server may need to be restarted.
Signed-off-by: Ian Molton ian.mol...@collabora.co.uk
---
qemu-char.c | 177 -
qemu-char.h |2 +
qemu-config.c |3 +
vl.c |4 +
4 files changed, 147 insertions(+), 39 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index e202585..714c119 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1870,8 +1870,12 @@ typedef struct {
int max_size;
int do_telnetopt;
int do_nodelay;
+int reconnect;
int is_unix;
int msgfd;
+QemuOpts *opts;
+CharDriverState *chr;
+int (*setup)(QemuOpts *opts);
} TCPCharDriver;
static void tcp_chr_accept(void *opaque);
@@ -2011,6 +2015,69 @@ static ssize_t tcp_chr_recv(CharDriverState *chr, char *buf, size_t len)
}
#endif
+struct reconnect_list {
+TCPCharDriver *s;
+uint64_t when;
+struct reconnect_list *next;
+};
+
+static struct reconnect_list *rc_list;
+
+static int qemu_chr_sched_reconnect(TCPCharDriver *s)
+{
+struct reconnect_list *new = qemu_malloc(sizeof(*new));
+struct timeval tv;
+
+if(!new)
+return 1;
+
+gettimeofday(tv, NULL);
+new-s = s;
+new-when = (s-reconnect + tv.tv_sec) * 100 + tv.tv_usec;
+new-next = rc_list;
+rc_list = new;
+
+return 0;
+}
+
+static int qemu_chr_connect_socket(TCPCharDriver *s);
+
+void qemu_chr_reconnect(void)
+{
+struct reconnect_list *this = rc_list, *prev = NULL;
+struct timeval tv;
+uint64_t now;
+
+if(!this)
+return;
+
+gettimeofday(tv, NULL);
+now = tv.tv_sec * 100 + tv.tv_usec;
+
+while (this) {
+if (this-when = now) {
+if(qemu_chr_connect_socket(this-s)) {
+if(prev)
+prev-next = this-next;
+else
+rc_list = NULL;
+qemu_chr_event(this-s-chr, CHR_EVENT_RECONNECTED);
+free(this);
+ if(prev)
+ this = prev;
+ else
+ this = NULL;
+}
+else {
+this-when += this-s-reconnect * 100;
+}
+}
+prev = this;
+ if(this)
+this = this-next;
+}
+}
+
static void tcp_chr_read(void *opaque)
{
CharDriverState *chr = opaque;
@@ -2030,10 +2097,16 @@ static void tcp_chr_read(void *opaque)
if (s-listen_fd = 0) {
qemu_set_fd_handler(s-listen_fd, tcp_chr_accept, NULL, chr);
}
-qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+if (!s-reconnect)
+qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
closesocket(s-fd);
s-fd = -1;
-qemu_chr_event(chr, CHR_EVENT_CLOSED);
+if (!s-reconnect) {
+qemu_chr_event(chr, CHR_EVENT_CLOSED);
+} else if (qemu_chr_sched_reconnect(s)) {
+printf(Unable to queue socket for reconnection.\n);
+qemu_chr_event(chr, CHR_EVENT_CLOSED);
+}
} else if (size 0) {
if (s-do_telnetopt)
tcp_chr_process_IAC_bytes(chr, s, buf, size);
@@ -2137,7 +2210,6 @@ static CharDriverState *qemu_chr_open_socket(QemuOpts *opts)
{
CharDriverState *chr = NULL;
TCPCharDriver *s = NULL;
-int fd = -1;
int is_listen;
int is_waitconnect;
int do_nodelay;
@@ -2145,34 +2217,40 @@ static CharDriverState *qemu_chr_open_socket(QemuOpts *opts)
int is_telnet;
is_listen = qemu_opt_get_bool(opts, server, 0);
+is_unix= qemu_opt_get(opts, path) != NULL;
+
is_waitconnect = qemu_opt_get_bool(opts, wait, 1);
is_telnet = qemu_opt_get_bool(opts, telnet, 0);
do_nodelay = !qemu_opt_get_bool(opts, delay, 1);
-is_unix= qemu_opt_get(opts, path) != NULL;
-if (!is_listen)
+
+if (!is_listen) {
is_waitconnect = 0;
+} else {
+if (is_telnet)
+s-do_telnetopt = 1;
+}
+
-chr = qemu_mallocz(sizeof(CharDriverState));
s = qemu_mallocz(sizeof(TCPCharDriver));
+chr = qemu_mallocz(sizeof(CharDriverState));
+s-opts = opts;
+
+
Re: [Qemu-devel] Socket reconnection.
Ian Molton wrote: Anthony Liguori wrote: sleep() in qemu is very, very wrong. It will pause the guest's execution and all sorts of badness can ensue. Quite... The right thing to do is set a timer and not generate data while disconnected. New patch attached, now with less crack... I still am not confident this is really a great thing to do. What other option is there than to drop the ability to feed entropy to the guest when the hosts egd link drops? btw. Does anyone know how to get t-bird to inline patches? -Ian Ah, your mailer didn't attach it correctly... Anyway, it's broken wrt CodingStyle. Regards, Anthony Liguori
RE: [Qemu-devel] Socket reconnection.
Hello Ian,
Pasting chunks, then commenting:
+static int qemu_chr_sched_reconnect(TCPCharDriver *s)
+{
+struct reconnect_list *new = qemu_malloc(sizeof(*new));
+struct timeval tv;
+
+if(!new)
+return 1;
Qemu_malloc will never return 0, so sched function can return void.
+while (this) {
+if (this-when = now) {
+if(qemu_chr_connect_socket(this-s)) {
+if(prev)
+prev-next = this-next;
+else
+rc_list = NULL;
+qemu_chr_event(this-s-chr, CHR_EVENT_RECONNECTED);
+free(this);
+ if(prev)
+ this = prev;
+ else
+ this = NULL;
+}
+else {
+this-when += this-s-reconnect * 100;
+}
+}
+prev = this;
+ if(this)
+this = this-next;
This is a mixture of tabs and spaces, for new code pick one.
The if(prev) can just be this = prev; if prev is NULL you want NULL
anyway.
Thanks
Chris
-Original Message-
From: Ian Molton [mailto:ian.mol...@collabora.co.uk]
Sent: Wednesday, December 02, 2009 4:41 AM
To: Anthony Liguori
Cc: Krumme, Chris; qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Socket reconnection.
Anthony Liguori wrote:
sleep() in qemu is very, very wrong. It will pause the guest's
execution and all sorts of badness can ensue.
Quite...
The right thing to do is set a timer and not generate data while
disconnected.
New patch attached, now with less crack...
I still am not confident this is really a great thing to do.
What other option is there than to drop the ability to feed entropy to
the guest when the hosts egd link drops?
btw. Does anyone know how to get t-bird to inline patches?
-Ian
RE: [Qemu-devel] Socket reconnection.
Hello Ian,
Since you did not inline your source I will paste in a chunk:
@@ -2030,10 +2036,18 @@ static void tcp_chr_read(void *opaque)
if (s-listen_fd = 0) {
qemu_set_fd_handler(s-listen_fd, tcp_chr_accept, NULL,
chr);
}
-qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+if (!s-reconnect)
+qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
closesocket(s-fd);
s-fd = -1;
-qemu_chr_event(chr, CHR_EVENT_CLOSED);
+if (!s-reconnect) {
+qemu_chr_event(chr, CHR_EVENT_CLOSED);
+} else {
+do {
+sleep(s-reconnect);
+} while(!qemu_chr_connect_socket(s));
+qemu_chr_event(chr, CHR_EVENT_RECONNECTED);
+}
} else if (size 0) {
if (s-do_telnetopt)
tcp_chr_process_IAC_bytes(chr, s, buf, size);
Should you be introducing a while sleep loop into Qemu here?
I would think you should be returning 'no data', maybe after trying
once.
Hope this helps.
Chris
-Original Message-
From:
qemu-devel-bounces+chris.krumme=windriver@nongnu.org
[mailto:qemu-devel-bounces+chris.krumme=windriver@nongnu.o
rg] On Behalf Of Ian Molton
Sent: Tuesday, December 01, 2009 5:54 AM
To: Anthony Liguori
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Socket reconnection.
Anthony Liguori wrote:
Ian Molton wrote:
Hi folks,
I need my source of data for virtio-rng to be reliable -
IOW. if the
server dies and comes back up, I want qemu to reconnect
and suck down
fresh entropy, rather than hand the rngd process on the guest.
I'm using the chardev 'socket' type to make the connection
to the host.
Would a patch adding (optional) auto-reconnect (with a
back-off delay)
to the socket chardev be acceptable ?
If not, I'll have to cook up a thread to handle EGD
requests, but that
seems perverse...
Hrm, I'm not sure. What are the circumstances that this connection
would die? What happens while the connection is dead?
The most common would be the entropy gathering daemon being restarted,
perhaps due to an upgrade. Its hardly a good idea to require all the
guest VMs to reboot on this occuring. Next most common I
guess would be
the daemon crashing, but again, not something you'd want
taking out your
guest VMs...
Whilst the connection is down, the guests will potentially starve of
entropy - but that only means they'll block processes that try to use
/dev/random if they run out altogether.
Here are two patches that implement socket reconnection. This first
cleans up the APIs needed a little and the second implements
the guts.
If these patches are acceptable, I will repost my 4-patch series which
also includes the SIZE parameter patch and an updated virtio-rng patch
that uses the reconnection infrastructure to enhance its reliability.
-Ian
Re: [Qemu-devel] Socket reconnection.
Krumme, Chris wrote: Hello Ian, Hi! Should you be introducing a while sleep loop into Qemu here? I would think you should be returning 'no data', maybe after trying once. Indeed. I could have sworn I tried that. Too much crack, will re-do.
Re: [Qemu-devel] Socket reconnection.
Krumme, Chris wrote:
Hello Ian,
Since you did not inline your source I will paste in a chunk:
@@ -2030,10 +2036,18 @@ static void tcp_chr_read(void *opaque)
if (s-listen_fd = 0) {
qemu_set_fd_handler(s-listen_fd, tcp_chr_accept, NULL,
chr);
}
-qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+if (!s-reconnect)
+qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
closesocket(s-fd);
s-fd = -1;
-qemu_chr_event(chr, CHR_EVENT_CLOSED);
+if (!s-reconnect) {
+qemu_chr_event(chr, CHR_EVENT_CLOSED);
+} else {
+do {
+sleep(s-reconnect);
+} while(!qemu_chr_connect_socket(s));
+qemu_chr_event(chr, CHR_EVENT_RECONNECTED);
+}
} else if (size 0) {
if (s-do_telnetopt)
tcp_chr_process_IAC_bytes(chr, s, buf, size);
Should you be introducing a while sleep loop into Qemu here?
I would think you should be returning 'no data', maybe after trying
once.
Hope this helps.
Chris
sleep() in qemu is very, very wrong. It will pause the guest's
execution and all sorts of badness can ensue.
The right thing to do is set a timer and not generate data while
disconnected. I still am not confident this is really a great thing to do.
Regards,
Anthony Liguori
Re: [Qemu-devel] Socket reconnection.
Ian Molton wrote: Hi folks, I need my source of data for virtio-rng to be reliable - IOW. if the server dies and comes back up, I want qemu to reconnect and suck down fresh entropy, rather than hand the rngd process on the guest. I'm using the chardev 'socket' type to make the connection to the host. Would a patch adding (optional) auto-reconnect (with a back-off delay) to the socket chardev be acceptable ? If not, I'll have to cook up a thread to handle EGD requests, but that seems perverse... Hrm, I'm not sure. What are the circumstances that this connection would die? What happens while the connection is dead? Regards, Anthony Liguori -Ian
Re: [Qemu-devel] Socket reconnection.
Ian Molton wrote: Hi folks, I need my source of data for virtio-rng to be reliable - IOW. if the server dies and comes back up, I want qemu to reconnect and suck down fresh entropy, rather than hand the rngd process on the guest. I'm using the chardev 'socket' type to make the connection to the host. Would a patch adding (optional) auto-reconnect (with a back-off delay) to the socket chardev be acceptable ? If not, I'll have to cook up a thread to handle EGD requests, but that seems perverse... I'm a bit puzzled. Why isn't virtio-rng getting entropy from /dev/random on the host? -- Jamie
Re: [Qemu-devel] Socket reconnection.
Hi, Would a patch adding (optional) auto-reconnect (with a back-off delay) to the socket chardev be acceptable ? Sounds sensible to me. And, yes, it should be an option (defaulting to off to maintain current behavior when not specified). cheers, Gerd
