Xen devel - Dec 2006 - [Xen-ia64-devel] [PATCH][RFC][IA64] Accelerate IDE PIO on HVM/IA64

This patch significantly accelerates IDE PIO on HVM/IA64:
* reduces the installation time of Windows 2003 Server
  from 10 hours(!) to 50min.
* accelerates Windows CrashDumping speed from 40KB/sec
  (It takes over three hours for 512MB guest) to 850KB/sec.

All reason for above slowness is the overhead of IDE PIO.
Of course Windows should use DMA mode but we can''t handle it.
(FYI. Once installed, Windows usually uses DMA mode)

On the other hand, x86 arch is rescued from this issue since it has a
CISC instruction and multiple PIO requests can be processed in qemu-dm
at one transaction. So this patch gives no benefit for x86.

There are some dirty hacks in this patch:
* To begin with, is it permissive to delegate the part of process of
qemu-dm to hypervisor?
* Currently it uses remnant of buffered_iopage (for VGA).
  Maybe I should prepare another page for IDE PIO.
* May I use "#ifdef __ia64__" ?
* and so on.

Please show me the right way.

Thanks,
Kouya

Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Quoting Kouya SHIMURA <kouya@jp.fujitsu.com>:
> This patch significantly accelerates IDE PIO on HVM/IA64:
> * reduces the installation time of Windows 2003 Server
>   from 10 hours(!) to 50min.
> * accelerates Windows CrashDumping speed from 40KB/sec
>   (It takes over three hours for 512MB guest) to 850KB/sec.
>
> All reason for above slowness is the overhead of IDE PIO.
> Of course Windows should use DMA mode but we can''t handle it.
> (FYI. Once installed, Windows usually uses DMA mode)
>
> On the other hand, x86 arch is rescued from this issue since it has a
> CISC instruction and multiple PIO requests can be processed in qemu-dm
> at one transaction. So this patch gives no benefit for x86.
>
> There are some dirty hacks in this patch:
> * To begin with, is it permissive to delegate the part of process of
> qemu-dm to hypervisor?
> * Currently it uses remnant of buffered_iopage (for VGA).
>   Maybe I should prepare another page for IDE PIO.
> * May I use "#ifdef __ia64__" ?
> * and so on.
Hi,

clever idea!

Two remarks:
* you can''t assume page size = 16KB.  Xen can be compiled with other
page
sizes (and should work with other page sizes).  As an easy approach, you can
disable this optimization iff page size != 16KB (or use smaller buffers).
* To be written data are not flushed directly.  I suppose they are flushed
while status is checked.  Is it safe ?

Tristan.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Hi, Tristan

Thanks for your comments.

* In any case, I have to allocate another page for IDE PIO buffer.
  Actually this patch works well on any size of buffer. The size is
  just trade-off with the performance. FYI, 2048 bytes seems to be
  enough for CDROM.

* The location where data is being written has already been enclosed
  with the memory barrier. Since shared memory is used for the
  communication between hypervisor and qemu-dm. So I think it''s safe.

  Actually it isn''t guest''s MP safe but I think guest OS must
take
  responsibility for it. (Who reads the I/O port simultaneously?)

Thanks,
Kouya

tgingold@free.fr writes:
 > Quoting Kouya SHIMURA <kouya@jp.fujitsu.com>:
 > 
 > > This patch significantly accelerates IDE PIO on HVM/IA64:
 > > * reduces the installation time of Windows 2003 Server
 > >   from 10 hours(!) to 50min.
 > > * accelerates Windows CrashDumping speed from 40KB/sec
 > >   (It takes over three hours for 512MB guest) to 850KB/sec.
 > >
 > > All reason for above slowness is the overhead of IDE PIO.
 > > Of course Windows should use DMA mode but we can''t handle
it.
 > > (FYI. Once installed, Windows usually uses DMA mode)
 > >
 > > On the other hand, x86 arch is rescued from this issue since it has a
 > > CISC instruction and multiple PIO requests can be processed in
qemu-dm
 > > at one transaction. So this patch gives no benefit for x86.
 > >
 > > There are some dirty hacks in this patch:
 > > * To begin with, is it permissive to delegate the part of process of
 > > qemu-dm to hypervisor?
 > > * Currently it uses remnant of buffered_iopage (for VGA).
 > >   Maybe I should prepare another page for IDE PIO.
 > > * May I use "#ifdef __ia64__" ?
 > > * and so on.
 > Hi,
 > 
 > clever idea!
 > 
 > Two remarks:
 > * you can''t assume page size = 16KB.  Xen can be compiled with
other page
 > sizes (and should work with other page sizes).  As an easy approach, you
can
 > disable this optimization iff page size != 16KB (or use smaller buffers).
 > * To be written data are not flushed directly.  I suppose they are flushed
 > while status is checked.  Is it safe ?
 > 
 > Tristan.
 > 
 > _______________________________________________
 > Xen-devel mailing list
 > Xen-devel@lists.xensource.com
 > http://lists.xensource.com/xen-devel


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Hi Kouya,
    With your patch, win2k3 installation can be done within 40 minutes!
    I have integrated #Cset12525 with the accelerating patch. 
    It took 20 minutes to load file (you will see it in a blue screen).
And then the guest quickly installed the win2k3 from the CD-ROM, totally
within 40 minutes! 
    What a wonderful patch! :)

Thanks,
Zhangjingke
>-----Original Message-----
>From: xen-ia64-devel-bounces@lists.xensource.com
>[mailto:xen-ia64-devel-bounces@lists.xensource.com] On Behalf Of Kouya
>SHIMURA
>Sent: Monday, December 04, 2006 10:28 AM
>To: xen-devel@lists.xensource.com; xen-ia64-devel@lists.xensource.com
>Subject: [Xen-ia64-devel] [PATCH][RFC][IA64] Accelerate IDE PIO on
>HVM/IA64
>
>This patch significantly accelerates IDE PIO on HVM/IA64:
>* reduces the installation time of Windows 2003 Server
>  from 10 hours(!) to 50min.
>* accelerates Windows CrashDumping speed from 40KB/sec
>  (It takes over three hours for 512MB guest) to 850KB/sec.
>
>All reason for above slowness is the overhead of IDE PIO.
>Of course Windows should use DMA mode but we can''t handle it.
>(FYI. Once installed, Windows usually uses DMA mode)
>
>On the other hand, x86 arch is rescued from this issue since it has a
>CISC instruction and multiple PIO requests can be processed in qemu-dm
>at one transaction. So this patch gives no benefit for x86.
>
>There are some dirty hacks in this patch:
>* To begin with, is it permissive to delegate the part of process of
>qemu-dm to hypervisor?
>* Currently it uses remnant of buffered_iopage (for VGA).
>  Maybe I should prepare another page for IDE PIO.
>* May I use "#ifdef __ia64__" ?
>* and so on.
>
>Please show me the right way.
>
>Thanks,
>Kouya
>
>Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 5 Dec 2006 11:19:38 +0900
Kouya SHIMURA <kouya@jp.fujitsu.com> wrote:
> Hi, Tristan
> 
> Thanks for your comments.
> 
> * In any case, I have to allocate another page for IDE PIO buffer.
>   Actually this patch works well on any size of buffer. The size is
>   just trade-off with the performance. FYI, 2048 bytes seems to be
>   enough for CDROM.
You want a bit more if you ever begin to support multimedia or READ/WRITE
LONG, that can get you up to about 2500 bytes per "sector".

You also need to watch that you handle inb/inw/inl on the data port
properly as devices can support 32bit I/O on the data port which is not
the same as a 32bit I/O usually is (it does not return the value of port,
port +1, port + 2, port +3). Or you can report that 32bit I/O is not
supported in the drive identify page..

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, Alan

Multimedia was out of my thought since my target is IA64. 
What a gorgeous music player it is! :)

For handling inb/inw/inl, I already support inw/inl except inb.
inb is processed with the previous mechanism.
All I did is to move ide_data_(read|write)[wl] functions in Qemu 
into the hypervisor.

Thanks,
Kouya

Alan writes:
 > You want a bit more if you ever begin to support multimedia or READ/WRITE
 > LONG, that can get you up to about 2500 bytes per "sector".
 > 
 > You also need to watch that you handle inb/inw/inl on the data port
 > properly as devices can support 32bit I/O on the data port which is not
 > the same as a 32bit I/O usually is (it does not return the value of port,
 > port +1, port + 2, port +3). Or you can report that 32bit I/O is not
 > supported in the drive identify page..
 > 
 > Alan
 > 
 > _______________________________________________
 > Xen-devel mailing list
 > Xen-devel@lists.xensource.com
 > http://lists.xensource.com/xen-devel


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel