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

[Al Boldi <a1426z@xxxxxxxxx>]

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 
enough?

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!

--
Al


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