[Qemu-devel] qemu/hw ide.c

2006-02-01 Thread Fabrice Bellard 
CVSROOT:/sources/qemu
Module name:qemu
Branch: 
Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/02/01 22:20:12

Modified files:
hw : ide.c 

Log message:
correct DMA and transfer mode reporting (Jens Axboe)

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ide.c.diff?tr1=1.38&tr2=1.39&r1=text&r2=text


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu vl.c

2006-02-01 Thread Fabrice Bellard 
CVSROOT:/sources/qemu
Module name:qemu
Branch: 
Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/02/01 21:29:26

Modified files:
.  : vl.c 

Log message:
win32 socket support

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.158&tr2=1.159&r1=text&r2=text


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH 2/3] ide lba48 support

2006-02-01 Thread Fabrice Bellard 

Jens Axboe wrote:

Subject: [PATCH] Add lba48 support to ide
From: Jens Axboe <[EMAIL PROTECTED]>
Date: 1136376117 +0100

Add lba48 support for the ide code. Read back of hob registers isn't
there yet, though.


Do you have a more recent patch ? In your latest patch, the lba48 field 
is never reset and the nsector may be broken.


Fabrice.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] A simple way to DMA (and async. IO) to make win2003 happy

2006-02-01 Thread Fabrice Bellard 

Juergen Pfennig wrote:

Hello ...

Please note: I will send the Async IO stuff later, see below.

This Patch: Here is a very simple patch to ide.c that does not change
the controller type and that lets an existing win2003 in-
stallation use multi-sector IO and/or DMA.

> [...]

I just merged a more complete patch from Jens Axboe. Does it give 
acceptable performance in win2003 ?



(3) My way to async IO is different, read below. The implementation
does async read and write. My plans are to make the SDL async too.

(4) The async IO layer integrates well with Fabrice Bellard's IOHandlers.
In fact vl.c needs no modifications, the code uses a pipe to signal
that IO got ready. The modifications on the block driver layer are
minimal.

To say this again: the async IO stuff itself is about 600 lines of code
(in one file) but it needs several small changes in qemu. Here are some
fake definitions that you might help you to get a first impression:


So there are two async I/O patches now :-)

I am more interested by these patches now because I want to improve the 
performance to match (or exceed !) the performance of the other 
virtualizers. I have at least 5 items on my TODO list :


1) New kqemu which virtualizes both user and kernel code (currently in 
alpha stage but not released yet).


2) DMA block I/O (merged)

3) async block I/O (not merged yet)

4) Network adapter using DMA (not merged yet)

5) VGA acceleration (either improve Cirrus VGA or switch back to Bochs 
VGA for Win 2000/XP or Linux)


Fabrice.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu block-cloop.c block-dmg.c

2006-02-01 Thread Fabrice Bellard 
CVSROOT:/sources/qemu
Module name:qemu
Branch: 
Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/02/01 21:43:52

Modified files:
.  : block-cloop.c block-dmg.c 

Log message:
use uint8_t instead of char

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/block-cloop.c.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/block-dmg.c.diff?tr1=1.3&tr2=1.4&r1=text&r2=text


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel][PATCH] Tap and VLAN socket support for win32

2006-02-01 Thread Fabrice Bellard 
Hi,

I merged your patches and I made important changes to simplify them. I
did not do any tests so tell me if you see problems.

Regards,

Fabrice.

Kazu wrote:
> Hi,
> 
> I updated a patch to support tap for win32.
> 
> Here is patches and a binary.
> These patches are applied by patch -p1 option. Tap patch can be applied on
> top of VLAN patch. VLAN patch is updated.
> http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060111-vlan.patch
> http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060111-tap.patch
> 
> http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060111-vlan-tap.zip
> 
> Options are:
> -net nic -net tap,ifname=my-tap
> Use ifname to set a name of Tap.
> my-tap is the name of  my TAP-Win32 Adapter.
> 
> Don't use the same network address as a physical network.
> For example, if the physical network is 192.168.0.x, use different 
> network 192.168.10.y for TAP-Win32 Adapter.
> 
> For more information,
> http://www.h7.dion.ne.jp/~qemu-win/TapWin32-en.html#vlan
> 
> Regards,
> Kazu
> 
> 
> 
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu Makefile.target vl.c vl.h tap-win32.c

2006-02-01 Thread Fabrice Bellard 
CVSROOT:/sources/qemu
Module name:qemu
Branch: 
Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/02/01 23:06:55

Modified files:
.  : Makefile.target vl.c vl.h 
Added files:
.  : tap-win32.c 

Log message:
tap win32 support

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Makefile.target.diff?tr1=1.90&tr2=1.91&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.159&tr2=1.160&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.99&tr2=1.100&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/tap-win32.c?rev=1.1


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Qemu on Intel Macs

2006-02-01 Thread Paul Brook 
On Wednesday 01 February 2006 09:14, Mike Kronenberg wrote:
> Hi there,
>
> thanks to a tipster I had a look at your sheepshaver 2 days ago :).
> qemu dyngen.c is compiling with the added i386 mach lines. Later I
> had some problems with osdep.h which is used by the qemu tools. I
> disabled it for now.
>
> Now I stuck with:
> softmmu_header.h:204: error can't find a register in class
> 'GENERAL_REGS' while reloading 'asm'
> which is used by:
> target-i386:ops_template_mem.h:  In function
> 'op_cmpxchgb_kernel_T0_T1_EAX_CC
>
> I tried with and without the gcc4 fixes... and it seams to be another
> register issue which will be a lot of reading form me :)

It's a GCC bug (PR15482) triggered by trying to 64-bit operations after 
reserving most of the available registers for global register vars. 

There are patches here that may work around the problem:
http://lists.gnu.org/archive/html/qemu-devel/2005-11/msg00245.html

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu/hw ne2000.c

2006-02-01 Thread Fabrice Bellard 
CVSROOT:/sources/qemu
Module name:qemu
Branch: 
Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/02/01 21:40:18

Modified files:
hw : ne2000.c 

Log message:
rxcr save/restore (initial patch by Jürgen Pfennig

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ne2000.c.diff?tr1=1.17&tr2=1.18&r1=text&r2=text


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu configure

2006-02-01 Thread Fabrice Bellard 
CVSROOT:/sources/qemu
Module name:qemu
Branch: 
Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/02/01 21:45:16

Modified files:
.  : configure 

Log message:
added --enable-cocoa in help (Pavel Janík)

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/configure.diff?tr1=1.79&tr2=1.80&r1=text&r2=text


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] qemu qemu-doc.texi

2006-02-01 Thread Fabrice Bellard 
CVSROOT:/sources/qemu
Module name:qemu
Branch: 
Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/02/01 21:30:56

Modified files:
.  : qemu-doc.texi 

Log message:
clearer -net doc (Paul Brook)

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/qemu-doc.texi.diff?tr1=1.78&tr2=1.79&r1=text&r2=text


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] VMDK block device as a kernel module ?

2006-02-01 Thread Bogdan Harjoc 
Hello, I haven't been watching qemu development too closely but AFAIK (anda quick search through the list archives says the same thing) there haven't been any efforts in building the vmware block driver as a kernel
(block device) driver. This would of course be a complete waste of somebody's time _except_ (arguably) for something like booting a kernel natively but mounting root (et cetera) from a .vmdk file.
I would equally appreciate any pointer towards somebody's attempt at doing this or an opinion on whether it is worth doing at all (althoughthe FUSE framework would probably make a first attempt worthwhile).
Cheers,Bogdan.
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] 16550A FIFO emulation

2006-02-01 Thread bcanet 

Hi,

This is a small patch I wrote to add 16550A FIFO emulation to QEMU.
The main motivation to write this patch was the slowliness of the QEMU serial 
port when the guest operating system is under high load. 
With the 16450 UART an interrupt is generated for every byte send or received.
With FIFO support fewer interrupt are generated.
If anybody has suggestions to improve the correctness/cleanliness of the 
emulation just tell me.

Best regards

Benoît Canet
Dental-On-Line
25a26
> 
41a43,46
> #define UART_IIR_CTI0x0C/* Character Timeout Indication */
> 
> #define UART_IIR_FENF   0x80/* Fifo enabled, but not functionning */
> #define UART_IIR_FE 0xC0/* Fifo enabled */
72a78,190
> /*
>  * These are the definitions for the Fifo Control Register
>  */
> 
> #define UART_FCR_ITL_MASQ   0xC0 /* Masq for Interrupt Trigger Level */
> 
> #define UART_FCR_ITL_1  0x00 /* 1 byte Interrupt Trigger Level */
> #define UART_FCR_ITL_4  0x40 /* 4 bytes Interrupt Trigger Level */
> #define UART_FCR_ITL_8  0x80 /* 8 bytes Interrupt Trigger Level */
> #define UART_FCR_ITL_14 0xC0 /* 14 bytes Interrupt Trigger Level */
> 
> #define UART_FCR_DMS0x08/* DMA Mode Select */
> #define UART_FCR_XFR0x04/* XMIT Fifo Reset */
> #define UART_FCR_RFR0x02/* RCVR Fifo Reset */
> #define UART_FCR_FE 0x01/* FIFO Enable */
> 
> #define UART_FIFO_LENGTH16 /* 16550A Fifo Length */
> 
> struct SerialFifo {
> char *data; /* bytes contained by the fifo */
> unsigned int count; /* number of byte in the fifo */
> unsigned int length;/* length of the fifo */
> unsigned int trigger;   /* trigger level of the fifo */
> } typedef SerialFifo;
> 
> /* initialize a FIFO */
> SerialFifo * fifo_init(unsigned int length, unsigned int trigger) {
> SerialFifo *f;
> if(!length)
> return NULL;
> if(trigger>length)
> return NULL;
> f = qemu_mallocz(sizeof(SerialFifo));
> if(f == NULL)
> return NULL;
> f->data = qemu_mallocz(length);
> if(f->data == NULL) {
> qemu_free(f);
> return NULL;
> }
> f->length = length;
> f->count = 0;
> f->trigger = trigger;
> return f;
> }
> 
> /* set the trigger level of a FIFO */
> int fifo_set_trigger(SerialFifo *f, unsigned int trigger) {
> f->trigger = trigger;
> return 1;
> }
> 
> /* clear a FIFO */
> int fifo_clear(SerialFifo *f) {
> f->count = 0;
> return 1;
> }
> 
> 
> /* free the memory of the FIFO - unused */
> int fifo_free(SerialFifo *f) {
> if(f->data != NULL)
> qemu_free(f->data);
> qemu_free(f);
> return 1;
> }
> 
> /* put a character in the FIFO */
> int fifo_put(SerialFifo *f, uint8_t *buf, int size) {
> if(f->count >= f->length)
> return 0;
> /* Do the fifo moving */
> memmove(f->data+f->count, buf, size);
> f->count += size;
> return 1;
> }
> 
> /* get the FIFO triggering level */
> unsigned int fifo_get_trigger(SerialFifo *f) {
> return f->trigger;
> }
> 
> 
> /* get the first char of the FIFO */
> char fifo_get(SerialFifo *f) {
> char c;
> if(f->count == 0)
> return (char) 0;
> f->count -= 1;
> c = f->data[0];
> memmove(f->data, f->data+1, f->count);
> return c;
> }
> 
> unsigned int fifo_count(SerialFifo *f) {
> return f->count;
> }
> 
> unsigned int fifo_is_full(SerialFifo *f) {
> if(f->count >= f->length)
> return 1;
> else
> return 0;
> }
> 
> /* Used to test if the FIFO trigger level is reached */
> unsigned int fifo_is_triggered(SerialFifo *f) {
> if(f->count >= f->trigger)
> return 1;
> else
> return 0;
> }
> 
82a201
> uint8_t fcr;
92a212,218
> int output_fifo_count;  /* number of byte in the simulated XMIT FIFO */
> int64_t output_start_time;  /* Time when the first byte has been put in the XMIT FIFO */
> SerialFifo *input_fifo;
> float char_transmit_time;   /* time to transmit a char */
> struct QEMUTimer *fifo_timeout_timer;
> int timeout_ipending;   /* timeout interrupt pending state */
> struct QEMUTimer *fifo_transmit_timer;
94a221,222
> 
> 
97,98c225,232
< if ((s->lsr & UART_LSR_DR) && (s->ier & UART_IER_RDI)) {
< s->iir = UART_IIR_RDI;
---
> if ((s->lsr & UART_LSR_OE) && (s->ier & UART_IER_RLSI)) {
> s->iir = (s->iir& UART_IIR_FE) | UART_IIR_RLSI;
> } else if ((s->lsr & UART_LSR_DR) && (s->ier & UART_IER_RDI) && (s->fcr & UART_FCR_FE) && fifo_is_triggered(s->input_fifo) ) {
> s->iir = (s->iir& UART_IIR_FE) | UART_IIR_RDI;
> } else if ((s->lsr & UART_LSR_DR) && (s->ier & UART_IER_RDI) && !((s->fcr & UART_FCR_FE) != 0) ) {
> s->iir = (s->iir& UART_IIR_FE) | UART_IIR_RDI;
> } else if (s->timeout_ipending) {
>  s->iir = (s->iir& UART_IIR_FE) | UART_IIR_CTI;
100c234
< s->iir = UAR

Re: [Qemu-devel] Qemu on Intel Macs

2006-02-01 Thread Mike Kronenberg 

Hi there,

thanks to a tipster I had a look at your sheepshaver 2 days ago :).  
qemu dyngen.c is compiling with the added i386 mach lines. Later I  
had some problems with osdep.h which is used by the qemu tools. I  
disabled it for now.


Now I stuck with:
softmmu_header.h:204: error can't find a register in class  
'GENERAL_REGS' while reloading 'asm'

which is used by:
target-i386:ops_template_mem.h:  In function  
'op_cmpxchgb_kernel_T0_T1_EAX_CC


I tried with and without the gcc4 fixes... and it seams to be another  
register issue which will be a lot of reading form me :)


Mike

On 01.02.2006, at 07:48, Gwenole Beauchesne wrote:


Hi,

Anyone out there feel qualified to help me get this going? Its a  
bit beyond my ability at this time and I would be happy to  
compensate for time.


I still haven't had the time to merge back to QEMU the following  
change:


Probably on next weekend...


Jeshua Lacock ___
Programmer/OwnerPhone:  877.240.1364
http://OpenOSX.com  Fax:415.462.6211
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_


Ah, you claimed that Wintel^WBochs ran at near native performance,  
how would you communicate on QEMU then?




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] Crash of qemu while compiling using ant under emlulated x86_64 (hosted on ix86)

2006-02-01 Thread Yannick Patois 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I have a reproducable bug, but involving a rather complex setup, before
attempting to track this down, I would like to know if this is already
known.

Versions note for the host system:
> uname -a
Linux 2.4.21-37.EL.cernsmp #1 SMP i686 i686 i386 GNU/Linux
It's an SLC3 on a PIV computer.
qemu is compiled from a recent CVS checkout.

The target system is x86_64 running some (somewhat) misconfigured SLC3
(RHE3 derivates). Missconfigurations can comes from the fact that I
couldnt boot the slc3 installer from qemu and that I installed
it"manually" and have a few stranges things (dhcp doesnt work, wget
fails strangely). I know I should first clarify that, but until now,
this wasnt much a problem to me: it was working enough for what I wanted.

Anyway, when trying to compile some java code using ant (in the
blackdown x86_64 JVM), qemu crashed:

$ gdb /usr/local/src/ypatois/qemu/cvs/qemu/x86_64-softmmu/qemu-system-x86_64
set ARGS=-m 256 -net user -net nic -redir tcp:2200::22 -nographic -hda
hdb.img -hdc hdc.img
r
[...]
[EMAIL PROTECTED] edg-java-security]$ ant compile

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218571616 (LWP 18841)]
0x097c83ce in code_gen_buffer ()
(gdb) backtrace
#0  0x097c83ce in code_gen_buffer ()
#1  0x097acf89 in code_gen_buffer ()
#2  0x38a4f0a0 in ?? ()
#3  0x42b33b7a in ?? ()
#4  0x0809f87b in cpu_x86_exec (env1=0x8402360) at
/usr/local/src/ypatois/qemu/cvs/qemu/cpu-exec.c:747
#5  0x in ?? ()

I dont think this report helps a lot, unless what I'm talking about is
already know.
If not, how could I improve it to help the debugging?

Thanks.

Yannick

- --
 _/ Yannick Patois _ Address (home) __
| irc(undernet): Garp on #france25+ | 1, rue de Bale   |
| http://garp.feelingsurfer.net/| 67100 Strasbourg |
| Tel-home: +(33)(0)3 88 84 88 16   | FRANCE   |
| Le Portail des Copains : http://rezo.net |
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFD4Lm7ZY3s/IVpRFIRAjaiAJ46JXqM0OILi9Ma0SidbRjmS1qR4gCdGIyP
2xBmq51ZK0woZbL+cLxEvK8=
=1Aw5
-END PGP SIGNATURE-


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] A simple way to DMA (and async. IO) to make win2003 happy

2006-02-01 Thread Juergen Pfennig 
Hello ...

Please note: I will send the Async IO stuff later, see below.

This Patch: Here is a very simple patch to ide.c that does not change
the controller type and that lets an existing win2003 in-
stallation use multi-sector IO and/or DMA.

There is another patch for BSD (sorry, I am not sure about the author's
name - is it John?).  That patch changes the controler, modifies the
BIOS and adds a simple way for async writes. MY PATCH IS VERY DIFFERENT:

(1) The controller type is not changed. In qemu 8.0.0 some bits got set
wrong, windows therefore disabled DMA.

(2) I have no documentation about the controller. WHO CAN SEND ME THE
IDE CONTROLLER DOCUMENTATION? I took some ideas from John and
used the linux kernel source. UNFORTUNATELY not all off my bits
make the linux kernel happy - it complains and disables DMA. BUT
IT SHOULD BE EASY TO SORT THIS OUT.

(3) My way to async IO is different, read below. The implementation
does async read and write. My plans are to make the SDL async too.

(4) The async IO layer integrates well with Fabrice Bellard's IOHandlers.
In fact vl.c needs no modifications, the code uses a pipe to signal
that IO got ready. The modifications on the block driver layer are
minimal.

To say this again: the async IO stuff itself is about 600 lines of code
(in one file) but it needs several small changes in qemu. Here are some
fake definitions that you might help you to get a first impression:

8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<
#ifdef  QEMU_TOOL
// Global: start the background thread
int qaio_initialize(IoAsyncInst* inst, IoAsyncCall* spy) { return 0; }

// Global: terminate the background thread
int qaio_terminate(IoAsyncInst* inst) { return 0; }

// Global: IOHandler used to run the completion callback
void qaio_poll(void* opaque) {}

// Client: this function is only called once
int qaio_register(IoAsyncInst* i, IoAsyncItem** iptr, void* o, int file)
{   int* pfile = (int*)iptr; *pfile = file; return 0;   }

// Client: this function should be called to flush pending requests
int qaio_unregister(IoAsyncItem** iptr) { return 0; }

// Client: make this a child
int qaio_parent(IoAsyncItem* item, IoAsyncItem* parent) { return 0; }

// Client: begin a new request (flush or commit must follow)
int qaio_begin(IoAsyncItem* item, IoAsyncCall* cbf, void* info)
{   return 1;   }

// Client: commit any pending request
int qaio_commit(IoAsyncItem* item) { return 1; }

// Client: flush any pending request synchronously
int qaio_flush(IoAsyncItem* item) { return 1; }

// Client: queue a write request
int qaio_write(IoAsyncItem* item, const void* pdat, uint32_t count,
   uint64_t offs)
{   return qemu_write_at((int)item, pdat, count, offs); }

// Client: queue a read request
int qaio_read(IoAsyncItem* item, void* pdat, uint32_t count,
  uint64_t offs)
{   return qemu_read_at((int)item, pdat, count, offs); }
#endif
>8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8

The DMA stuff is very important for windows. With synchronous IO you
roughly get the following performance on a simple P4/2.4 GHz single disk
machine:

6 MByte/s   No Multi-Sector, no DMA (qemu 8.0.0 default)
9 MByte/s   Multi-Sector, no DMA (this Patch)
   12 MByte/s   with DMA (this Patch)

With async IO the throughput can go up further but this saturates my
workstation disk, so I will not quote any numbers here. I should also
mention that I use a faster block layer driver (called bkf) that I
will submit after it has matured for a while.

Whereas the DMA stuff fixes more or less a bug in qemu 8.0.0 the async
IO is really important. Here is why:

(1) The Windows GUI now works "smoothly". The emulated machine is more
responsive and the mouse cursor does not "hang". Please remember
that this also requires the hack to make VGA faster that I submitted
a while ago.
(2) The windows clock looses much fewer timer ticks and now mostly shows
the correct time. Perfmon now becomes really usable.
(3) Even under heavy IO load the CPU-usage now falls below 100% so that
CPU cycles are for other activity on the host or the emulated PC.
(4) Async IO does not generally speed-up batch operations, but the
emulated PC behaves more like a real one. Example: the animated
boot logo of windows.

Yours Juergen
Index: hw/ide.c
===
RCS file: /home/Cvsroot/qemu/hw/ide.c,v
retrieving revision 1.1.1.1
retrieving revision 1.9
diff -B -b -U3 -r1.1.1.1 -r1.9
--- hw/ide.c	14 Jan 2006 13:19:59 -	1.1.1.1
+++ hw/ide.c	1 Feb 2006 10:17:51 -	1.9
@@ -185,7 +185,7 @@
 #define DISABLE_SEAGATE			0xFB
 
 /* set to 1 set disable mult support */
-#define MAX_MULT_SECTORS 16
+#define MAX_MULT_SECTORS 256
 
 /* ATAPI