Re: [Qemu-devel] qemu guest agent spins in poll/nanosleep(100ms) when nothing is listening on host

[Daniel P. Berrange]

On Thu, Oct 06, 2011 at 04:15:07PM -0500, Michael Roth wrote:
> On Thu, 6 Oct 2011 12:31:05 +0100, "Daniel P. Berrange" <address@hidden> 
> wrote:
> > I get the feeling that this kind of problem inherant in the use of any
> > virtio-serial channel, in the same way you can't detect EOF for a regular
> > serial device channel either. Given that virtio-serial is a nice paravirt
> > device, is there anything we can do to it, to allow better handling of
> > EOF by applications ?
> 
> Indeed, and there was a discussion a while back where I think we had tentative
> agreement on a path forward for this. Unfortunately there doesn't seem to be
> a clear solution for doing it purely in guest-userspace:
> 
> http://www.mail-archive.com/address@hidden/msg57002.html
> 
> The gist of it is basically making the (guest-side) virtio-serial chardev
> behave more like a unix socket, i.e. if the host hangs up you get a single EOF
> and then your FD becomes invalid, at which point you need to re-open the
> chardev to get a valid FD. This could potentially be done with via a new set 
> of
> -chardev/-device flags.

Ah interesting idea.

> > Or perhaps there is some way to make use of epoll() in edge-triggered
> > mode to detect it already, because IIUC, edge-triggered mode should only
> > fire once for the EOF condition, and then not fire again until something
> > in the host actually sends some data ?
> > 
> > Of course glib's event loop doesn't support edge-triggered events/epoll,
> > but perhaps we could just call epoll() directly in the event handler,
> > instead of the usleep() call ?
> 
> That's definitely worth looking into. Has the 100ms sleep been causing any
> issues though? My main concern with the polling behavior was less a matter of
> performance than being able to provide a "session" where the start and end
> of a stream could be reliably determined, which we don't have currently. But
> the guest agent has since been reworked to persist state between host
> connects/disconnects so it didn't seem to be a major issue anymore.

We're intending to have the agent installed in all Fedora 16 guests and
later guests by default, and used by libvirt for shutdown/reboot. so I
was just looking at how it was working to ensure there are no surprises
and happened to notice the wakeups when disconnected on the host. So it
hasn't actually caused any problems for me, I just have a general desire
to ensure any code doesn't do frequent wakeups when there's no work todo.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|