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

[Tristan Gingold <tgingold@xxxxxxx>]

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.

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