[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] KVM call minutes 2013-01-29
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] KVM call minutes 2013-01-29 |
Date: |
Tue, 29 Jan 2013 18:36:31 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
Il 29/01/2013 17:47, Anthony Liguori ha scritto:
> Paolo Bonzini <address@hidden> writes:
>
>> Il 29/01/2013 16:41, Juan Quintela ha scritto:
>>> * Replacing select(2) so that we will not hit the 1024 fd_set limit in the
>>> future. (stefan)
>>>
>>> Add checks for fd's bigger than 1024? multifunction devices uses lot
>>> of fd's for device.
>>>
>>> Portability?
>>> Use glib? and let it use poll underneath.
>>> slirp is a problem.
>>> in the end loop: moving to a glib event loop, how we arrive there is the
>>> discussion.
>>
>> We can use g_poll while keeping the main-loop.c wrappers around the glib
>> event loop. Both slirp and iohandler.c access the fd_sets randomly, so
>> we need to remember some state between the fill and poll functions. We
>> can use two main-loop.c functions:
>>
>> int qemu_add_poll_fd(int fd, int events);
>>
>> select: writes the events into three fd_sets, returns the file
>> descriptor itself
>>
>> poll: writes a GPollFD into a dynamically-sized array (of GPollFDs)
>> and returns the index in the array.
>>
>> int qemu_get_poll_fd_revents(int index);
>>
>> select: takes the file descriptor (returned by qemu_add_poll_fd),
>> makes up revents based on the three fd_sets
>>
>> poll: takes the index into the array and returns the corresponding
>> revents
>>
>> iohandler.c can simply store the index into struct IOHandlerRecord, and
>> use it later. slirp can do the same for struct socket.
>>
>> The select code can be kept for Windows after POSIX switches to poll.
>
> Doesn't g_poll already do this under the covers for Windows?
No, g_poll is for synchronization objects (like Linux eventfd or
timerfd). Sockets still require select. You can tie a socket to a
synchronization object; this way socket events can exit g_poll, and in
fact that's exactly what QEMU does. But you still need to retrieve the
currently-active events with select, so iohandler.c and slirp (which use
sockets) need to work in terms of select.
Paolo
- [Qemu-devel] KVM call minutes 2013-01-29, Juan Quintela, 2013/01/29
- Re: [Qemu-devel] KVM call minutes 2013-01-29, Paolo Bonzini, 2013/01/29
- Re: [Qemu-devel] KVM call minutes 2013-01-29, Alexander Graf, 2013/01/29
- Re: [Qemu-devel] KVM call minutes 2013-01-29, Anthony Liguori, 2013/01/29
- [Qemu-devel] What to do about non-qdevified devices? (was: KVM call minutes 2013-01-29), Markus Armbruster, 2013/01/30
- Re: [Qemu-devel] What to do about non-qdevified devices?, Andreas Färber, 2013/01/30
- Re: [Qemu-devel] What to do about non-qdevified devices? (was: KVM call minutes 2013-01-29), Peter Maydell, 2013/01/30
- Re: [Qemu-devel] What to do about non-qdevified devices?, Markus Armbruster, 2013/01/30
- Re: [Qemu-devel] What to do about non-qdevified devices?, Andreas Färber, 2013/01/30
- Re: [Qemu-devel] What to do about non-qdevified devices?, Paolo Bonzini, 2013/01/30
- Re: [Qemu-devel] What to do about non-qdevified devices?, Andreas Färber, 2013/01/30
- Re: [Qemu-devel] What to do about non-qdevified devices?, Markus Armbruster, 2013/01/31