[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Improving hvm IO performance by using self IO emulator (YA io-emu?)

  • To: Tristan Gingold <tgingold@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Thu, 22 Feb 2007 07:59:35 +0000
  • Delivery-date: Wed, 21 Feb 2007 23:58:45 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdWV2RnouDNzsJKEduXfgAWy6hiGQ==
  • Thread-topic: [Xen-devel] Improving hvm IO performance by using self IO emulator (YA io-emu?)

On 22/2/07 05:23, "Tristan Gingold" <tgingold@xxxxxxx> wrote:

> The current IO emulator (ioemu process in dom-0) is a well known bottleneck
> for hvm performance because IO requests travel is long and cross many rings.
> Many ideas to improve the emulation have been proposed.  None of them have
> been adopted because their approach are too disruptive.
> Based on my recent firmware experience I'd like to propose a new method.

This sounds plausible. It probably depends on what kind of 'firmware'
environment you plan to drop the ioemu code into? The general idea of
emulated devices looking to the control stack like PV I/O is one that we
want for x86 as well. So any xend changes to that effect are welcome.

> * From the hypervisor point of view such an hvm domain looks like a PV domain:
> only the creation differs.  This IO emulation method unifies the domain.  This
> will simplify save & restore and Xen in general.

I don't know the specifics of ia64 VTi, but I'd expect that Xen will still
need to be aware of VTi? I'd be surprised if the differences can be hidden
safely and efficiently. The model you propose sounds much more to me like a
VTi (non-PV) domain with PV extensions in an extended firmware module.

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.