Tim Meddick wrote:
> While what you say is perfectly true concerning software running inside VPC
> and attempting to access hardware resources, with the exception of any
> cd/dvd drives and floppy disk drives attached to the system.
>
> The VPC application is able to gain access to these devices, as, if it
> could not, the installation of guest operating systems could not be done
> using cd/dvd-roms or by floppy disk.
>
> Having said all this, Virtual PC provides support for some PC's which
> posses Hardware Assisted Virtualization. Although this feature is not
> common, if your PC has it, hardware *would* then be accessible to a guest
> OS running in a VPC window.
The only real hardware available inside a virtual machine is the CPU.
All other hardware is emulated or a pass-through *driver* is used.
Pass-through mode to connect a real CD drive to emulate a CD drive
inside the VM is *not* accessing the hardware directly (which, for
example, would be to access the hardware interface of a device by its
address). The passthrough mode permits redirection of the emulated
device to the kernel-mode driver for the real device. DOS programs that
directly access the hardware weren't going through a driver which
provided an API to the OS and apps running at kernel level to provide
the actual physical interface to the device. The lack of a USB
pass-through adapter in VirtualPC is why you can't use USB devices
inside of it. HID devices, like mice and keyboard, are completely
emulated (no pass-through mode) and why a USB foot pedal listed as a HID
device in Device Manager still cannot be seen into the VM. While
VirtualPC 2007 has no pass-through mode for USB devices, the Windows
Virtual PC (XP Mode in Windows 7) does have a pass-through mode for USB
devices. In Windows 7's XP mode, there is redirection permitted for USB
storage devices. That redirection goes to the driver that provides the
interface between OS and device. It is not providing direct access to
the the device to an app, like the guest running under a VMM. Under
DOS, you can access a device without using a driver for it. That's what
I mean by direct access. For example, and only from memory, I think
address 80 was for the first IDE mass storage device (hard disk) and 81
was for the second one (in the order they were detected by the BIOS).
It was possible to remove a hard disk partition by using debug.exe which
sent commands directly to the device, not through system API calls or
driver interfaces.
The CPU is directly accessible but often reported by the VMM as
something else (and how some malware can detect they are running inside
a VM so they remain quiescent hoping you'll install them outside the
VM). That's it. The pass-through drivers provide their own interface
from the emulated device to the real hardware. The VMM on the host has
to provide the redirection for the USB, serial, and parallel devices
inside the guest. Because of this *redirection*, you can disconnect the
guest's CD drive and connect it to any other physical drive on the host.
All the rest is emulated hardware.
HAV (hardware-assisted virtualization) only provides hardware-level code
to more quickly what would be needed by software emulation. In some
cases, HAV can actually slow the VM. As I recall reading about
Sun/Oracle VirtualBox, they actually recommended disabling HAV because
the made slower the responsiveness of their VM (i.e., the code for their
software emulation was better optimized than the firmware on the CPU's
die). HAV does *not* magically provide direct access to hardware
devices from inside a VM. I don't recall if HAV helps or hinders
performance for VPC. HAV is for helping the VMM (Virtual Machine
Manager) do its job or to eliminate translation for guest system calls,
not alter the emulated environment generated by the VMM. The VMM can
use HAV. The HAV eliminates [some of] the abstraction layer needed
between guest and VMM. Yeah, you can access hardware from the guest if
you use standard kernel API calls but not if you attempt direct access
to the hardware device's interface (i.e., you are not using the system
API). The HAV assists the VMM, not bypasses it. It is an enabler for
full virtualization so an unmodified OS can run as a guest (in a VM).
Putting the translations for the abstraction layer or VM traps into
firmware doesn't suddenly change how the scheme works. It facilitates
the use of the faster hardware instead of having to use the slower
software. Hardware is always faster than software (well, usually that's
true unless the firmware is not optimized). The VMM remains in control
of the virtualized environment that it defines to the guest. If it
doesn't, it is a "leaky" VMM and not worthy as a contender in today's
competition for VMMs.
Do some reading:
http://en.wikipedia.org/wiki/Hardware-assisted_virtualization