From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tristan Gingold Subject: Re: Re: Improving hvm IO performance by using self IO emulator (YA io-emu?) Date: Sat, 24 Feb 2007 07:17:47 +0100 Message-ID: <20070224061747.GC2508@saphi> References: <20070222052309.GA2764@saphi> <45DDBF76.1030805@us.ibm.com> <1172177938.45de041286155@imp.free.fr> <200702222124.16755.mark.williamson@cl.cam.ac.uk> <45DE0C21.20605@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <45DE0C21.20605@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: tgingold@free.fr, xen-devel@lists.xensource.com, Mark Williamson List-Id: xen-devel@lists.xenproject.org On Thu, Feb 22, 2007 at 03:33:21PM -0600, Anthony Liguori wrote: > Mark Williamson wrote: [...] > >Mmmm. It's not like the guest can break security if it tampers with the > >device models in its own memory space. > > > >Question: how does this compare with using a "stub domain" to run the > >device models? The previous proposed approach was to automatically switch > >to the stub domain on trapping an IO by the HVM guest, and have that stub > >domain run the device models, etc. > > > > Reflecting is a bit more expensive than doing a stub domain. There is > no way to wire up the VMEXITs to go directly into the guest so you're > always going to have to pay the cost of going from guest => host => > guest => host => guest for every PIO. The guest is incapable of > reenabling PG on its own hence the extra host => guest transition. > > Compare to stub domain where, if done correctly, you can go from guest > => host/0 => host/3 => host/0 => guest. The question would be, is > host/0 => host/3 => host/0 fundamentally faster than host => guest => host. > > I know that guest => host => guest typically costs *at least* 1000 nsecs > on SVM. A null sysenter syscall (that's host/3 => host/0 => host/3) is > roughly 75 nsecs. > > So my expectation is that stub domain can actually be made to be faster > than reflecting. Ok. Unfortunatly I don't have the figures for ia64. With the firmware approach strictly speaking we don't need to reenter into the guest mode during the reflection. That would be very like stub-domain. [I really have to look on stub-domain implementation if there is such one]. Tristan.