[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [patch] IDE busmaster DMA support
From: |
Troy Benjegerdes |
Subject: |
Re: [Qemu-devel] [patch] IDE busmaster DMA support |
Date: |
Tue, 27 Sep 2005 11:33:09 -0500 |
User-agent: |
Mutt/1.5.9i |
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.