* [Qemu-devel] Do we need CONFIG_AIO? @ 2009-05-25 8:21 Christoph Hellwig 2009-05-25 11:49 ` Stefano Stabellini 0 siblings, 1 reply; 15+ messages in thread From: Christoph Hellwig @ 2009-05-25 8:21 UTC (permalink / raw) To: qemu-devel Currently all aio code in the raw-posix block driver depends on a CONFIG_AIO symbol that gets set based on the availability of the pthreads library. Beeing able to rely on unconditional aio support means we could remove the whole code for plain bdrv_read/bdrv_write in raw-posix.c which is about 300 lines of code and a duplicated code path. Is there any Posix-ish platform qemu supports that does not have pthreads support? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 8:21 [Qemu-devel] Do we need CONFIG_AIO? Christoph Hellwig @ 2009-05-25 11:49 ` Stefano Stabellini 2009-05-25 12:29 ` Christoph Hellwig ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Stefano Stabellini @ 2009-05-25 11:49 UTC (permalink / raw) To: Christoph Hellwig; +Cc: qemu-devel@nongnu.org Christoph Hellwig wrote: > Currently all aio code in the raw-posix block driver depends on a > CONFIG_AIO symbol that gets set based on the availability of the > pthreads library. Beeing able to rely on unconditional aio support > means we could remove the whole code for plain bdrv_read/bdrv_write > in raw-posix.c which is about 300 lines of code and a duplicated code > path. Is there any Posix-ish platform qemu supports that does not > have pthreads support? > MiniOS. I would appreciate if you keep that flag. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 11:49 ` Stefano Stabellini @ 2009-05-25 12:29 ` Christoph Hellwig 2009-05-25 12:58 ` Samuel Thibault 2009-05-25 13:35 ` Todd T. Fries 2009-05-26 7:58 ` Anthony Liguori 2 siblings, 1 reply; 15+ messages in thread From: Christoph Hellwig @ 2009-05-25 12:29 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Christoph Hellwig, qemu-devel@nongnu.org On Mon, May 25, 2009 at 12:49:08PM +0100, Stefano Stabellini wrote: > > Currently all aio code in the raw-posix block driver depends on a > > CONFIG_AIO symbol that gets set based on the availability of the > > pthreads library. Beeing able to rely on unconditional aio support > > means we could remove the whole code for plain bdrv_read/bdrv_write > > in raw-posix.c which is about 300 lines of code and a duplicated code > > path. Is there any Posix-ish platform qemu supports that does not > > have pthreads support? > > > > MiniOS. > I would appreciate if you keep that flag. I can't find MiniOS mentioned anywhere in the qemu tree. From googling around it seems to be some Xen demo kernel. Do you plan to merge support for it one day? And what's the use case for qemu on MiniOS? If it's anything performance sensitive the lack of aio will cause quite severe stalling of the guest. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 12:29 ` Christoph Hellwig @ 2009-05-25 12:58 ` Samuel Thibault 2009-05-25 13:00 ` Christoph Hellwig 0 siblings, 1 reply; 15+ messages in thread From: Samuel Thibault @ 2009-05-25 12:58 UTC (permalink / raw) To: Christoph Hellwig; +Cc: qemu-devel@nongnu.org, Stefano Stabellini Christoph Hellwig, le Mon 25 May 2009 14:29:29 +0200, a écrit : > On Mon, May 25, 2009 at 12:49:08PM +0100, Stefano Stabellini wrote: > > > Is there any Posix-ish platform qemu supports that does not have > > > pthreads support? > > > > > > > MiniOS. > > I would appreciate if you keep that flag. > > I can't find MiniOS mentioned anywhere in the qemu tree. From googling > around it seems to be some Xen demo kernel. Do you plan to merge > support for it one day? And what's the use case for qemu on MiniOS? > If it's anything performance sensitive the lack of aio will cause quite > severe stalling of the guest. qemu on MiniOS is used to provide efficient full virtualisation, so yes it's performance sensitive, but for performances we use a block-vbd interface. Keeping the block-posix interface for non-performance critical resources that can not go through vbd is still important, so we need to be able to compile it. Samuel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 12:58 ` Samuel Thibault @ 2009-05-25 13:00 ` Christoph Hellwig 2009-05-25 13:26 ` Stefano Stabellini 0 siblings, 1 reply; 15+ messages in thread From: Christoph Hellwig @ 2009-05-25 13:00 UTC (permalink / raw) To: Samuel Thibault Cc: qemu-devel@nongnu.org, Christoph Hellwig, Stefano Stabellini On Mon, May 25, 2009 at 02:58:52PM +0200, Samuel Thibault wrote: > qemu on MiniOS is used to provide efficient full virtualisation, so yes > it's performance sensitive, but for performances we use a block-vbd > interface. Keeping the block-posix interface for non-performance > critical resources that can not go through vbd is still important, so we > need to be able to compile it. Apparently all this is not in upstream qemu, right? I really don't see the reason to keep all this stuff around for out of tree bits only given it is a significant burden. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 13:00 ` Christoph Hellwig @ 2009-05-25 13:26 ` Stefano Stabellini 0 siblings, 0 replies; 15+ messages in thread From: Stefano Stabellini @ 2009-05-25 13:26 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Samuel Thibault, qemu-devel@nongnu.org Christoph Hellwig wrote: > On Mon, May 25, 2009 at 02:58:52PM +0200, Samuel Thibault wrote: >> qemu on MiniOS is used to provide efficient full virtualisation, so yes >> it's performance sensitive, but for performances we use a block-vbd >> interface. Keeping the block-posix interface for non-performance >> critical resources that can not go through vbd is still important, so we >> need to be able to compile it. > > Apparently all this is not in upstream qemu, right? I really don't see > the reason to keep all this stuff around for out of tree bits only > given it is a significant burden. > I completely agree with you, but I couldn't find the time to merge all the bits yet. I hope to find more time in the next 6 months. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 11:49 ` Stefano Stabellini 2009-05-25 12:29 ` Christoph Hellwig @ 2009-05-25 13:35 ` Todd T. Fries 2009-05-25 13:40 ` Christoph Hellwig 2009-05-25 13:47 ` Avi Kivity 2009-05-26 7:58 ` Anthony Liguori 2 siblings, 2 replies; 15+ messages in thread From: Todd T. Fries @ 2009-05-25 13:35 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Christoph Hellwig, qemu-devel@nongnu.org Penned by Stefano Stabellini on 20090525 12:49.08, we have: | Christoph Hellwig wrote: | | > Currently all aio code in the raw-posix block driver depends on a | > CONFIG_AIO symbol that gets set based on the availability of the | > pthreads library. Beeing able to rely on unconditional aio support | > means we could remove the whole code for plain bdrv_read/bdrv_write | > in raw-posix.c which is about 300 lines of code and a duplicated code | > path. Is there any Posix-ish platform qemu supports that does not | > have pthreads support? | > | | MiniOS. | I would appreciate if you keep that flag. You seem to be under the illusion that pthreads implies AIO. OpenBSD has two flavors of threads libraries (arguably one is not fit for consumption yet) and neither provide AIO. This flag is most useful for OpenBSD as well. Thanks, -- Todd Fries .. todd@fries.net _____________________________________________ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | "..in support of free software solutions." \ 250797 (FWD) | \ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 13:35 ` Todd T. Fries @ 2009-05-25 13:40 ` Christoph Hellwig 2009-05-25 13:47 ` Avi Kivity 1 sibling, 0 replies; 15+ messages in thread From: Christoph Hellwig @ 2009-05-25 13:40 UTC (permalink / raw) To: todd; +Cc: qemu-devel@nongnu.org, Christoph Hellwig, Stefano Stabellini On Mon, May 25, 2009 at 08:35:55AM -0500, Todd T. Fries wrote: > You seem to be under the illusion that pthreads implies AIO. I'm not just under the illusion, but in the context of qemu we do implement our own aio support using pthread. And that's exactly what CONFIG_AIO enables. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 13:35 ` Todd T. Fries 2009-05-25 13:40 ` Christoph Hellwig @ 2009-05-25 13:47 ` Avi Kivity 2009-05-25 15:24 ` Todd T. Fries 1 sibling, 1 reply; 15+ messages in thread From: Avi Kivity @ 2009-05-25 13:47 UTC (permalink / raw) To: todd; +Cc: qemu-devel@nongnu.org, Christoph Hellwig, Stefano Stabellini Todd T. Fries wrote: > Penned by Stefano Stabellini on 20090525 12:49.08, we have: > | Christoph Hellwig wrote: > | > | > Currently all aio code in the raw-posix block driver depends on a > | > CONFIG_AIO symbol that gets set based on the availability of the > | > pthreads library. Beeing able to rely on unconditional aio support > | > means we could remove the whole code for plain bdrv_read/bdrv_write > | > in raw-posix.c which is about 300 lines of code and a duplicated code > | > path. Is there any Posix-ish platform qemu supports that does not > | > have pthreads support? > | > > | > | MiniOS. > | I would appreciate if you keep that flag. > > You seem to be under the illusion that pthreads implies AIO. > He isn't. > OpenBSD has two flavors of threads libraries (arguably one is not > fit for consumption yet) and neither provide AIO. > > This flag is most useful for OpenBSD as well. > Qemu's CONFIG_AIO requires thread support from the host, not posix aio support. -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 13:47 ` Avi Kivity @ 2009-05-25 15:24 ` Todd T. Fries 2009-05-25 15:27 ` Avi Kivity 0 siblings, 1 reply; 15+ messages in thread From: Todd T. Fries @ 2009-05-25 15:24 UTC (permalink / raw) To: Avi Kivity; +Cc: qemu-devel@nongnu.org, Christoph Hellwig, Stefano Stabellini Penned by Avi Kivity on 20090525 16:47.14, we have: > Todd T. Fries wrote: >> Penned by Stefano Stabellini on 20090525 12:49.08, we have: >> | Christoph Hellwig wrote: >> | | > Currently all aio code in the raw-posix block driver depends on a >> | > CONFIG_AIO symbol that gets set based on the availability of the >> | > pthreads library. Beeing able to rely on unconditional aio support >> | > means we could remove the whole code for plain bdrv_read/bdrv_write >> | > in raw-posix.c which is about 300 lines of code and a duplicated code >> | > path. Is there any Posix-ish platform qemu supports that does not >> | > have pthreads support? >> | > | | MiniOS. >> | I would appreciate if you keep that flag. >> >> You seem to be under the illusion that pthreads implies AIO. >> > > He isn't. > >> OpenBSD has two flavors of threads libraries (arguably one is not >> fit for consumption yet) and neither provide AIO. >> >> This flag is most useful for OpenBSD as well. >> > > Qemu's CONFIG_AIO requires thread support from the host, not posix aio > support. If thats the way things work, great. I just recall when AIO made its debut in qemu we had to figure out some strange workarounds.. -- Todd Fries .. todd@fries.net _____________________________________________ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | "..in support of free software solutions." \ 250797 (FWD) | \ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 15:24 ` Todd T. Fries @ 2009-05-25 15:27 ` Avi Kivity 0 siblings, 0 replies; 15+ messages in thread From: Avi Kivity @ 2009-05-25 15:27 UTC (permalink / raw) To: todd; +Cc: qemu-devel@nongnu.org, Christoph Hellwig, Stefano Stabellini Todd T. Fries wrote: >> Qemu's CONFIG_AIO requires thread support from the host, not posix aio >> support. >> > > If thats the way things work, great. I just recall when AIO made its debut > in qemu we had to figure out some strange workarounds.. > Things have changed, mostly due to EGLIBC's crappy aio implementation. -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-25 11:49 ` Stefano Stabellini 2009-05-25 12:29 ` Christoph Hellwig 2009-05-25 13:35 ` Todd T. Fries @ 2009-05-26 7:58 ` Anthony Liguori 2009-05-26 8:19 ` Christoph Hellwig 2009-05-26 10:02 ` Stefano Stabellini 2 siblings, 2 replies; 15+ messages in thread From: Anthony Liguori @ 2009-05-26 7:58 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Christoph Hellwig, qemu-devel@nongnu.org Stefano Stabellini wrote: > Christoph Hellwig wrote: > > >> Currently all aio code in the raw-posix block driver depends on a >> CONFIG_AIO symbol that gets set based on the availability of the >> pthreads library. Beeing able to rely on unconditional aio support >> means we could remove the whole code for plain bdrv_read/bdrv_write >> in raw-posix.c which is about 300 lines of code and a duplicated code >> path. Is there any Posix-ish platform qemu supports that does not >> have pthreads support? >> >> > > MiniOS. > I would appreciate if you keep that flag. > Threads are not going to be able to remain an optional dependency forever. I would be willing to merge something to remove CONFIG_AIO although I expect that there will be some fall out. Some people are using --disable-aio today for either historic reasons or because there are weird bugs with AIO enabled. Regards, Anthony Liguori ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-26 7:58 ` Anthony Liguori @ 2009-05-26 8:19 ` Christoph Hellwig 2009-05-26 10:02 ` Stefano Stabellini 1 sibling, 0 replies; 15+ messages in thread From: Christoph Hellwig @ 2009-05-26 8:19 UTC (permalink / raw) To: Anthony Liguori Cc: qemu-devel@nongnu.org, Christoph Hellwig, Stefano Stabellini On Tue, May 26, 2009 at 02:58:09AM -0500, Anthony Liguori wrote: > Threads are not going to be able to remain an optional dependency > forever. I would be willing to merge something to remove CONFIG_AIO > although I expect that there will be some fall out. Some people are > using --disable-aio today for either historic reasons or because there > are weird bugs with AIO enabled. Btw, this is the example patch I had in mind. Also when finishing up the configure bits I noticed DragonflyBSD currently does disable aio (but not pthreads in general), but that's the only platform I found. Index: qemu/block/raw-posix.c =================================================================== --- qemu.orig/block/raw-posix.c 2009-05-26 10:10:43.787976336 +0200 +++ qemu/block/raw-posix.c 2009-05-26 10:12:03.328027500 +0200 @@ -26,9 +26,7 @@ #include "qemu-char.h" #include "block_int.h" #include "module.h" -#ifdef CONFIG_AIO #include "posix-aio-compat.h" -#endif #ifdef CONFIG_COCOA #include <paths.h> @@ -102,7 +100,7 @@ typedef struct BDRVRawState { int fd; int type; - unsigned int lseek_err_cnt; + int flags; int open_flags; #if defined(__linux__) /* linux floppy specific */ @@ -111,7 +109,6 @@ typedef struct BDRVRawState { int fd_got_error; int fd_media_changed; #endif - uint8_t* aligned_buf; } BDRVRawState; static int posix_aio_init(void); @@ -130,8 +127,6 @@ static int raw_open_common(BlockDriverSt posix_aio_init(); - s->lseek_err_cnt = 0; - s->open_flags |= O_BINARY; if ((flags & BDRV_O_ACCESS) == O_RDWR) { s->open_flags |= O_RDWR; @@ -156,15 +151,8 @@ static int raw_open_common(BlockDriverSt return ret; } s->fd = fd; - s->aligned_buf = NULL; - if ((flags & BDRV_O_NOCACHE)) { - s->aligned_buf = qemu_blockalign(bs, ALIGNED_BUFFER_SIZE); - if (s->aligned_buf == NULL) { - ret = -errno; - close(fd); - return ret; - } - } + s->flags = flags; + return 0; } @@ -196,282 +184,6 @@ static int raw_open(BlockDriverState *bs #endif */ -/* - * offset and count are in bytes, but must be multiples of 512 for files - * opened with O_DIRECT. buf must be aligned to 512 bytes then. - * - * This function may be called without alignment if the caller ensures - * that O_DIRECT is not in effect. - */ -static int raw_pread_aligned(BlockDriverState *bs, int64_t offset, - uint8_t *buf, int count) -{ - BDRVRawState *s = bs->opaque; - int ret; - - ret = fd_open(bs); - if (ret < 0) - return ret; - - if (offset >= 0 && lseek(s->fd, offset, SEEK_SET) == (off_t)-1) { - ++(s->lseek_err_cnt); - if(s->lseek_err_cnt <= 10) { - DEBUG_BLOCK_PRINT("raw_pread(%d:%s, %" PRId64 ", %p, %d) [%" PRId64 - "] lseek failed : %d = %s\n", - s->fd, bs->filename, offset, buf, count, - bs->total_sectors, errno, strerror(errno)); - } - return -1; - } - s->lseek_err_cnt=0; - - ret = read(s->fd, buf, count); - if (ret == count) - goto label__raw_read__success; - - DEBUG_BLOCK_PRINT("raw_pread(%d:%s, %" PRId64 ", %p, %d) [%" PRId64 - "] read failed %d : %d = %s\n", - s->fd, bs->filename, offset, buf, count, - bs->total_sectors, ret, errno, strerror(errno)); - - /* Try harder for CDrom. */ - if (bs->type == BDRV_TYPE_CDROM) { - lseek(s->fd, offset, SEEK_SET); - ret = read(s->fd, buf, count); - if (ret == count) - goto label__raw_read__success; - lseek(s->fd, offset, SEEK_SET); - ret = read(s->fd, buf, count); - if (ret == count) - goto label__raw_read__success; - - DEBUG_BLOCK_PRINT("raw_pread(%d:%s, %" PRId64 ", %p, %d) [%" PRId64 - "] retry read failed %d : %d = %s\n", - s->fd, bs->filename, offset, buf, count, - bs->total_sectors, ret, errno, strerror(errno)); - } - -label__raw_read__success: - - return (ret < 0) ? -errno : ret; -} - -/* - * offset and count are in bytes, but must be multiples of 512 for files - * opened with O_DIRECT. buf must be aligned to 512 bytes then. - * - * This function may be called without alignment if the caller ensures - * that O_DIRECT is not in effect. - */ -static int raw_pwrite_aligned(BlockDriverState *bs, int64_t offset, - const uint8_t *buf, int count) -{ - BDRVRawState *s = bs->opaque; - int ret; - - ret = fd_open(bs); - if (ret < 0) - return -errno; - - if (offset >= 0 && lseek(s->fd, offset, SEEK_SET) == (off_t)-1) { - ++(s->lseek_err_cnt); - if(s->lseek_err_cnt) { - DEBUG_BLOCK_PRINT("raw_pwrite(%d:%s, %" PRId64 ", %p, %d) [%" - PRId64 "] lseek failed : %d = %s\n", - s->fd, bs->filename, offset, buf, count, - bs->total_sectors, errno, strerror(errno)); - } - return -EIO; - } - s->lseek_err_cnt = 0; - - ret = write(s->fd, buf, count); - if (ret == count) - goto label__raw_write__success; - - DEBUG_BLOCK_PRINT("raw_pwrite(%d:%s, %" PRId64 ", %p, %d) [%" PRId64 - "] write failed %d : %d = %s\n", - s->fd, bs->filename, offset, buf, count, - bs->total_sectors, ret, errno, strerror(errno)); - -label__raw_write__success: - - return (ret < 0) ? -errno : ret; -} - - -/* - * offset and count are in bytes and possibly not aligned. For files opened - * with O_DIRECT, necessary alignments are ensured before calling - * raw_pread_aligned to do the actual read. - */ -static int raw_pread(BlockDriverState *bs, int64_t offset, - uint8_t *buf, int count) -{ - BDRVRawState *s = bs->opaque; - int size, ret, shift, sum; - - sum = 0; - - if (s->aligned_buf != NULL) { - - if (offset & 0x1ff) { - /* align offset on a 512 bytes boundary */ - - shift = offset & 0x1ff; - size = (shift + count + 0x1ff) & ~0x1ff; - if (size > ALIGNED_BUFFER_SIZE) - size = ALIGNED_BUFFER_SIZE; - ret = raw_pread_aligned(bs, offset - shift, s->aligned_buf, size); - if (ret < 0) - return ret; - - size = 512 - shift; - if (size > count) - size = count; - memcpy(buf, s->aligned_buf + shift, size); - - buf += size; - offset += size; - count -= size; - sum += size; - - if (count == 0) - return sum; - } - if (count & 0x1ff || (uintptr_t) buf & 0x1ff) { - - /* read on aligned buffer */ - - while (count) { - - size = (count + 0x1ff) & ~0x1ff; - if (size > ALIGNED_BUFFER_SIZE) - size = ALIGNED_BUFFER_SIZE; - - ret = raw_pread_aligned(bs, offset, s->aligned_buf, size); - if (ret < 0) - return ret; - - size = ret; - if (size > count) - size = count; - - memcpy(buf, s->aligned_buf, size); - - buf += size; - offset += size; - count -= size; - sum += size; - } - - return sum; - } - } - - return raw_pread_aligned(bs, offset, buf, count) + sum; -} - -static int raw_read(BlockDriverState *bs, int64_t sector_num, - uint8_t *buf, int nb_sectors) -{ - int ret; - - ret = raw_pread(bs, sector_num * 512, buf, nb_sectors * 512); - if (ret == (nb_sectors * 512)) - ret = 0; - return ret; -} - -/* - * offset and count are in bytes and possibly not aligned. For files opened - * with O_DIRECT, necessary alignments are ensured before calling - * raw_pwrite_aligned to do the actual write. - */ -static int raw_pwrite(BlockDriverState *bs, int64_t offset, - const uint8_t *buf, int count) -{ - BDRVRawState *s = bs->opaque; - int size, ret, shift, sum; - - sum = 0; - - if (s->aligned_buf != NULL) { - - if (offset & 0x1ff) { - /* align offset on a 512 bytes boundary */ - shift = offset & 0x1ff; - ret = raw_pread_aligned(bs, offset - shift, s->aligned_buf, 512); - if (ret < 0) - return ret; - - size = 512 - shift; - if (size > count) - size = count; - memcpy(s->aligned_buf + shift, buf, size); - - ret = raw_pwrite_aligned(bs, offset - shift, s->aligned_buf, 512); - if (ret < 0) - return ret; - - buf += size; - offset += size; - count -= size; - sum += size; - - if (count == 0) - return sum; - } - if (count & 0x1ff || (uintptr_t) buf & 0x1ff) { - - while ((size = (count & ~0x1ff)) != 0) { - - if (size > ALIGNED_BUFFER_SIZE) - size = ALIGNED_BUFFER_SIZE; - - memcpy(s->aligned_buf, buf, size); - - ret = raw_pwrite_aligned(bs, offset, s->aligned_buf, size); - if (ret < 0) - return ret; - - buf += ret; - offset += ret; - count -= ret; - sum += ret; - } - /* here, count < 512 because (count & ~0x1ff) == 0 */ - if (count) { - ret = raw_pread_aligned(bs, offset, s->aligned_buf, 512); - if (ret < 0) - return ret; - memcpy(s->aligned_buf, buf, count); - - ret = raw_pwrite_aligned(bs, offset, s->aligned_buf, 512); - if (ret < 0) - return ret; - if (count < ret) - ret = count; - - sum += ret; - } - return sum; - } - } - return raw_pwrite_aligned(bs, offset, buf, count) + sum; -} - -static int raw_write(BlockDriverState *bs, int64_t sector_num, - const uint8_t *buf, int nb_sectors) -{ - int ret; - ret = raw_pwrite(bs, sector_num * 512, buf, nb_sectors * 512); - if (ret == (nb_sectors * 512)) - ret = 0; - return ret; -} - -#ifdef CONFIG_AIO /***********************************************************/ /* Unix AIO using POSIX AIO */ @@ -629,7 +341,7 @@ static RawAIOCB *raw_aio_setup(BlockDriv * boundary. Tell the low level code to ensure that in case it's * not done yet. */ - if (s->aligned_buf) + if (s->flags & BDRV_O_NOCACHE) acb->aiocb.aio_flags |= QEMU_AIO_SECTOR_ALIGNED; acb->next = posix_aio_state->first_aio; @@ -702,13 +414,6 @@ static void raw_aio_cancel(BlockDriverAI raw_aio_remove(acb); } -#else /* CONFIG_AIO */ -static int posix_aio_init(void) -{ - return 0; -} -#endif /* CONFIG_AIO */ - static void raw_close(BlockDriverState *bs) { @@ -716,8 +421,6 @@ static void raw_close(BlockDriverState * if (s->fd >= 0) { close(s->fd); s->fd = -1; - if (s->aligned_buf != NULL) - qemu_free(s->aligned_buf); } } @@ -866,18 +569,14 @@ static BlockDriver bdrv_raw = { .instance_size = sizeof(BDRVRawState), .bdrv_probe = NULL, /* no probe for protocols */ .bdrv_open = raw_open, - .bdrv_read = raw_read, - .bdrv_write = raw_write, .bdrv_close = raw_close, .bdrv_create = raw_create, .bdrv_flush = raw_flush, -#ifdef CONFIG_AIO .bdrv_aio_readv = raw_aio_readv, .bdrv_aio_writev = raw_aio_writev, .bdrv_aio_cancel = raw_aio_cancel, .aiocb_size = sizeof(RawAIOCB), -#endif .bdrv_truncate = raw_truncate, .bdrv_getlength = raw_getlength, @@ -978,7 +677,7 @@ static int hdev_open(BlockDriverState *b #endif s->type = FTYPE_FILE; -#if defined(__linux__) && defined(CONFIG_AIO) +#if defined(__linux__) if (strstart(filename, "/dev/sg", NULL)) { bs->sg = 1; } @@ -1044,7 +743,6 @@ static int hdev_ioctl(BlockDriverState * return ioctl(s->fd, req, buf); } -#ifdef CONFIG_AIO static BlockDriverAIOCB *hdev_aio_ioctl(BlockDriverState *bs, unsigned long int req, void *buf, BlockDriverCompletionFunc *cb, void *opaque) @@ -1075,7 +773,6 @@ static BlockDriverAIOCB *hdev_aio_ioctl( return &acb->common; } -#endif #elif defined(__FreeBSD__) static int fd_open(BlockDriverState *bs) @@ -1134,24 +831,18 @@ static BlockDriver bdrv_host_device = { .bdrv_create = hdev_create, .bdrv_flush = raw_flush, -#ifdef CONFIG_AIO .bdrv_aio_readv = raw_aio_readv, .bdrv_aio_writev = raw_aio_writev, .bdrv_aio_cancel = raw_aio_cancel, .aiocb_size = sizeof(RawAIOCB), -#endif - .bdrv_read = raw_read, - .bdrv_write = raw_write, .bdrv_getlength = raw_getlength, /* generic scsi device */ #ifdef __linux__ .bdrv_ioctl = hdev_ioctl, -#ifdef CONFIG_AIO .bdrv_aio_ioctl = hdev_aio_ioctl, #endif -#endif }; #ifdef __linux__ @@ -1228,15 +919,11 @@ static BlockDriver bdrv_host_floppy = { .bdrv_create = hdev_create, .bdrv_flush = raw_flush, -#ifdef CONFIG_AIO .bdrv_aio_readv = raw_aio_readv, .bdrv_aio_writev = raw_aio_writev, .bdrv_aio_cancel = raw_aio_cancel, .aiocb_size = sizeof(RawAIOCB), -#endif - .bdrv_read = raw_read, - .bdrv_write = raw_write, .bdrv_getlength = raw_getlength, /* removable device support */ @@ -1305,15 +992,11 @@ static BlockDriver bdrv_host_cdrom = { .bdrv_create = hdev_create, .bdrv_flush = raw_flush, -#ifdef CONFIG_AIO .bdrv_aio_readv = raw_aio_readv, .bdrv_aio_writev = raw_aio_writev, .bdrv_aio_cancel = raw_aio_cancel, .aiocb_size = sizeof(RawAIOCB), -#endif - .bdrv_read = raw_read, - .bdrv_write = raw_write, .bdrv_getlength = raw_getlength, /* removable device support */ @@ -1323,9 +1006,7 @@ static BlockDriver bdrv_host_cdrom = { /* generic scsi device */ .bdrv_ioctl = hdev_ioctl, -#ifdef CONFIG_AIO .bdrv_aio_ioctl = hdev_aio_ioctl, -#endif }; #endif /* __linux__ */ @@ -1421,15 +1102,11 @@ static BlockDriver bdrv_host_cdrom = { .bdrv_create = hdev_create, .bdrv_flush = raw_flush, -#ifdef CONFIG_AIO .bdrv_aio_readv = raw_aio_readv, .bdrv_aio_writev = raw_aio_writev, .bdrv_aio_cancel = raw_aio_cancel, .aiocb_size = sizeof(RawAIOCB), -#endif - .bdrv_read = raw_read, - .bdrv_write = raw_write, .bdrv_getlength = raw_getlength, /* removable device support */ Index: qemu/Makefile =================================================================== --- qemu.orig/Makefile 2009-05-26 10:12:10.201963074 +0200 +++ qemu/Makefile 2009-05-26 10:12:25.209855741 +0200 @@ -74,10 +74,7 @@ BLOCK_OBJS+=nbd.o block.o aio.o ifdef CONFIG_WIN32 BLOCK_OBJS += block/raw-win32.o else -ifdef CONFIG_AIO -BLOCK_OBJS += posix-aio-compat.o -endif -BLOCK_OBJS += block/raw-posix.o +BLOCK_OBJS += block/raw-posix.o posix-aio-compat.o endif ifdef CONFIG_CURL Index: qemu/configure =================================================================== --- qemu.orig/configure 2009-05-26 10:13:16.706814350 +0200 +++ qemu/configure 2009-05-26 10:16:16.304814641 +0200 @@ -181,7 +181,6 @@ uname_release="" curses="yes" curl="yes" pthread="yes" -aio="yes" io_thread="no" nptl="yes" mixemu="no" @@ -246,7 +245,6 @@ audio_possible_drivers="oss sdl esd pa" if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then kqemu="yes" fi -aio="no" ;; NetBSD) bsd="yes" @@ -481,10 +479,6 @@ for opt do ;; --enable-mixemu) mixemu="yes" ;; - --disable-pthread) pthread="no" - ;; - --disable-aio) aio="no" - ;; --enable-io-thread) io_thread="yes" ;; --disable-blobs) blobs="no" @@ -620,8 +614,6 @@ echo " --oss-lib path to echo " --enable-uname-release=R Return R for uname -r in usermode emulation" echo " --sparc_cpu=V Build qemu for Sparc architecture v7, v8, v8plus, v8plusa, v9" echo " --disable-vde disable support for vde network" -echo " --disable-pthread disable pthread support" -echo " --disable-aio disable AIO support" echo " --enable-io-thread enable IO thread" echo " --disable-blobs disable installing provided firmware blobs" echo " --kerneldir=PATH look for kernel includes in PATH" @@ -1152,21 +1144,22 @@ fi # pthread probe PTHREADLIBS="" -if test "$pthread" = yes; then - pthread=no +pthread=no cat > $TMPC << EOF #include <pthread.h> int main(void) { pthread_mutex_t lock; return 0; } EOF - if $cc $ARCH_CFLAGS -o $TMPE $PTHREADLIBS $TMPC 2> /dev/null > /dev/null ; then - pthread=yes - PTHREADLIBS="-lpthread" - fi +if $cc $ARCH_CFLAGS -o $TMPE $PTHREADLIBS $TMPC 2> /dev/null > /dev/null ; then + pthread=yes + PTHREADLIBS="-lpthread" fi if test "$pthread" = no; then - aio=no - io_thread=no + echo + echo "Error: pthread check failed" + echo "Make sure to have the pthread libs and headers installed." + echo + exit 1 fi ########################################## @@ -1354,7 +1347,6 @@ echo "Documentation $build_docs" echo "uname -r $uname_release" echo "NPTL support $nptl" echo "vde support $vde" -echo "AIO support $aio" echo "IO thread $io_thread" echo "Install blobs $blobs" echo "KVM support $kvm" @@ -1666,10 +1658,6 @@ fi if test "$xen" = "yes" ; then echo "XEN_LIBS=-lxenstore -lxenctrl -lxenguest" >> $config_mak fi -if test "$aio" = "yes" ; then - echo "#define CONFIG_AIO 1" >> $config_h - echo "CONFIG_AIO=yes" >> $config_mak -fi if test "$io_thread" = "yes" ; then echo "CONFIG_IOTHREAD=yes" >> $config_mak echo "#define CONFIG_IOTHREAD 1" >> $config_h ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-26 7:58 ` Anthony Liguori 2009-05-26 8:19 ` Christoph Hellwig @ 2009-05-26 10:02 ` Stefano Stabellini 2009-05-26 13:25 ` Anthony Liguori 1 sibling, 1 reply; 15+ messages in thread From: Stefano Stabellini @ 2009-05-26 10:02 UTC (permalink / raw) To: Anthony Liguori; +Cc: Christoph Hellwig, qemu-devel@nongnu.org Anthony Liguori wrote: > Stefano Stabellini wrote: >> Christoph Hellwig wrote: >> >> >>> Currently all aio code in the raw-posix block driver depends on a >>> CONFIG_AIO symbol that gets set based on the availability of the >>> pthreads library. Beeing able to rely on unconditional aio support >>> means we could remove the whole code for plain bdrv_read/bdrv_write >>> in raw-posix.c which is about 300 lines of code and a duplicated code >>> path. Is there any Posix-ish platform qemu supports that does not >>> have pthreads support? >>> >>> >> MiniOS. >> I would appreciate if you keep that flag. >> > > Threads are not going to be able to remain an optional dependency > forever. I would be willing to merge something to remove CONFIG_AIO > although I expect that there will be some fall out. Some people are > using --disable-aio today for either historic reasons or because there > are weird bugs with AIO enabled. > Obviously I would prefer if threads remained optional too, but let's just focus on AIO for the moment: as Todd pointed out OpenBSD doesn't currently provide AIO and also some small libc, like newlib, do not have AIO either. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Qemu-devel] Do we need CONFIG_AIO? 2009-05-26 10:02 ` Stefano Stabellini @ 2009-05-26 13:25 ` Anthony Liguori 0 siblings, 0 replies; 15+ messages in thread From: Anthony Liguori @ 2009-05-26 13:25 UTC (permalink / raw) To: Stefano Stabellini; +Cc: Christoph Hellwig, qemu-devel@nongnu.org Stefano Stabellini wrote: > Anthony Liguori wrote: > > Obviously I would prefer if threads remained optional too, but let's > just focus on AIO for the moment: as Todd pointed out OpenBSD doesn't > currently provide AIO and also some small libc, like newlib, do not have > AIO either. > CONFIG_AIO is a misnomer. It no longer has anything to do with posix-aio. It's just a standard read/write IO with a thread pool. Regards, Anthony Liguori ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-05-26 13:25 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-05-25 8:21 [Qemu-devel] Do we need CONFIG_AIO? Christoph Hellwig 2009-05-25 11:49 ` Stefano Stabellini 2009-05-25 12:29 ` Christoph Hellwig 2009-05-25 12:58 ` Samuel Thibault 2009-05-25 13:00 ` Christoph Hellwig 2009-05-25 13:26 ` Stefano Stabellini 2009-05-25 13:35 ` Todd T. Fries 2009-05-25 13:40 ` Christoph Hellwig 2009-05-25 13:47 ` Avi Kivity 2009-05-25 15:24 ` Todd T. Fries 2009-05-25 15:27 ` Avi Kivity 2009-05-26 7:58 ` Anthony Liguori 2009-05-26 8:19 ` Christoph Hellwig 2009-05-26 10:02 ` Stefano Stabellini 2009-05-26 13:25 ` Anthony Liguori
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).