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

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

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].


Xen-devel mailing list



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