On Mon, Sep 26, 2005 at 09:48:25PM -0400, John Coiner wrote:
> 
> Hi,
> 
> Here's another patch to enable IDE DMA:
> 
>   http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html
> 
> This patch, like Juergen Lock's earlier patch from which it is derived, 
> replaces the virtual PIIX3 IDE controller with a PIIX4.
> 
> It applies cleanly to 0.7.2.
> 
> This patch extends the Windows 2000 install hack to work for DMA also -- 
> I installed and ran Windows 2000 with DMA enabled.
> 
> It'd be cool if QEMU supported nonblocking disk access -- if it would 
> let the guest resume running currently, while waiting for the disk to 
> finish seeking. This patch is a first step toward concurrent IO, which 
> would probably have to use busmastering DMA transfers to be efficient, 
> if it's going to be efficient at all.
> 
> Do people have ideas about how to implement concurrent IO? I have a 
> couple hazy ideas...
> 
> Can anyone shed light on the potential performance to be realized? For 
> example, how long does a context switch take in the guest? If it takes 
> 10ms (one disk seek) then there's probably no benefit to concurrent disk 
> IO. If a context switch takes 1ms, then the guest has opportunity to 
> make forward progress while awaiting an IDE interrupt.

I would strongly suggest attempting to make use of the Linux Async I/O
support.. this way the data from disk could be placed directly in
address space of the guest OS. 

Personally, I'd love to see nonblocking disk IO. I've tried running Qemu
using a disk image on an AFS filesystem, and having the guest be able to
continue while the filesystem is fetching data from the network would
make things much nicer.


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

Reply via email to