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/
Home Products Support Community News


Re: [Xen-devel] Questioning the Xen Design of the VMM

Daniel Stodden wrote:
> On Tue, 2006-08-08 at 17:10 +0300, Al Boldi wrote:
> > So HVM solves the problem, but why can't this layer be implemented in
> > software?
> the short answer at the cpu level is "because of the arcane nature of
> the x86 architecture" :/

Which AMDV/IntelVT supposedly solves?

> once the cpu problem has been solved, you'd need to emulate hardware
> resources an unmodified guest system attempts to drive. that again takes
> additional cycles. elimination of the peripheral hardware interfaces by
> putting the I/O layers on top of an abstract low-level path into the VMM
> is one of the reasons why xen is faster than others. many systems do
> this quite successfully, even for 'non-modified' guests like e.g.
> windows, by installing dedicated, virtualization aware drivers once the
> base installation went ok.

You mean "virtualization aware" drivers in the guest-OS?  Wouldn't this 
amount to a form of patching?

> > I'm sure there can't be a performance issue, as this virtualization
> > doesn't occur on the physical resource level, but is (should be) rather
> > implemented as some sort of a multiplexed routing algorithm, I think :)
> few device classes support resource sharing in that manner efficiently.
> peripheral devices in commodity platforms are inherently single-hosted
> and won't support unfiltered access by multiple driver instances in
> several guests.

Would this be due to the inability of the peripheral to switch contexts fast 

If so, how about a "AMDV/IntelVT" for peripherals?

> from the vmm perspective, it always boils down to emulating the device.
> howerver, with varying degrees of complexity regarding the translation
> of guest requests to physical access. it depends. ide, afaik is known to
> work comparatively well.

Probably because IDE follows a well defined API?

> an example of an area where it's getting more
> sportive would be network adapters.
> this is basically the whole problem when building virtualization layers
> for cots platforms: the device/driver landscape spreads to infinity :)
> since you'll have a hard time driving any possible combination by
> yourself, you need something else to do it. one solution are hosted
> vmms, running on top of an existing operating system. a second solution
> is what xen does: offload drivers to a modified guest system which can
> then carry the I/O load from the additional, nonprivileged guests as
> well.

Agreed; so let me rephrase the dilemma like this:
The PC platform was never intended to be used in a virtualizing scenario, and 
therefore does not contain the infrastructure to support this kind of a 
scenario efficiently, but this could easily be rectified by introducing 
simple extensions, akin to AMDV/IntelVT, on all levels of the PC hardware.

Is this a correct reading?

If so, has this been considered in the Xen design, so as to accommodate any 
future hwV/VT/VMX extensions easily and quickly?

Thanks for your input!


Xen-devel mailing list