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 >