WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Improving hvm IO performance by using self IO emulator (

To: Tristan Gingold <tgingold@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Improving hvm IO performance by using self IO emulator (YA io-emu?)
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070222052309.GA2764@saphi>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdWV2RnouDNzsJKEduXfgAWy6hiGQ==
Thread-topic: [Xen-devel] Improving hvm IO performance by using self IO emulator (YA io-emu?)
User-agent: Microsoft-Entourage/11.3.3.061214
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel