qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] add fd limitations for avoiding a buffer overfl


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] add fd limitations for avoiding a buffer overflow
Date: Mon, 28 Jan 2013 10:56:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

Il 25/01/2013 15:30, Stefan Hajnoczi ha scritto:
> Anthony, Paolo: Is there an alternative to select(2)?  I think this was
> discussed a bit during the glib event loop integration.
> 
> The two requirements I can think of are:
> 
> 1. Portable so that we don't have to write OS-specific versions (epoll,
> kqueue, etc).
> 
> 2. Sub-millisecond timeouts.
> 
> Maybe we can use timerfd (and emulate it on non-Linux hosts) and then
> fully use the glib event loop?

Switching the alarm timer to a timerfd-based GSource is indeed easy.  We
do not absolutely need sub-millisecond timeouts; non-Linux hosts can
just use poll's millisecond resolution in the GSource.

However, perhaps it would be good also to move the timer mechanism to
AioContext.  Then qemu_new_timer becomes a special case of
aio_new_timer, just like qemu_bh_new.  This would let BlockDriverStates
have timers that fire during a qemu_aio_wait().  It would fix the busy
waiting in bdrv_drain_all(), and it would help threaded device models
too.  But more refactoring is needed for this.

> Internally glib prefers poll(2) but will fall back to select(2) on weird
> OSes.  On Windows it has dedicated code.

The main obstacle for poll() is slirp, which likes to do random accesses
on fd_sets.

Perhaps it's a good topic for tomorrow's call.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]