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

[tgingold@xxxxxxx]

Quoting Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>:

> 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.
Yes that's the idea.

> 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?
Sure.
> I'd be surprised if the differences can be hidden
> safely and efficiently.
If we can get rid of the ioemu process the differences between hvm and PV will
be small, won't they ?

> The model you propose sounds much more to me like a
> VTi (non-PV) domain with PV extensions in an extended firmware module.
Yes, but this model should work with the ioemu process.

Tristan.

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