Hi,
I have a driver for a PCIe device, that is working on W2K8.
I installed the hypervisor and an XP SP3 VM on it.
When I go to the device manager in XP, my device is not listed.
In W2K8 it is listed, the driver is installed and working.
I’ve read somewhere about emulated/synthetic drivers, aso and was expecting for the device to become usable in the VM through some kind of synthetic driver.
Is it possible to use custom hardware in a VM, and if so, are there any HW and/or driver requirements?
Thanks
xxxxx@barco.com wrote:
Hi,
I have a driver for a PCIe device, that is working on W2K8.
I installed the hypervisor and an XP SP3 VM on it.
When I go to the device manager in XP, my device is not listed.
In W2K8 it is listed, the driver is installed and working.
I’ve read somewhere about emulated/synthetic drivers, aso and was expecting for the device to become usable in the VM through some kind of synthetic driver.
Is it possible to use custom hardware in a VM, and if so, are there any HW and/or driver requirements?
No. There are emulated drivers for graphics, printers, networking, HID,
and some USB devices, but certainly not for arbitrary custom hardware.
How would you expect that to work?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Well, I would expect that the calls to the hardware are intercepted, redirected to the (synthetic) driver in the VM, which in it’s turn redirects it via the VMBus to the ‘real’ driver residing in the parent partition (W2K8). Because it is a PCIe device, I would expect that there would already be a (synthetic) driver capable of doing this.
At least, I would expect that I was able to create a synthetic driver myself, so that the hardware is usable in a virtualized OS, or that the hardware could be assigned to a dedicated VM.
xxxxx@barco.com wrote:
Well, I would expect that the calls to the hardware are intercepted, redirected to the (synthetic) driver in the VM, which in it’s turn redirects it via the VMBus to the ‘real’ driver residing in the parent partition (W2K8). Because it is a PCIe device, I would expect that there would already be a (synthetic) driver capable of doing this.
Again, how would you do that? You don’t “call” into hardware. To
access a PCIe device, you read and write from chunks of simulated
memory, and some of those read and writes might trigger things like
bus-mastered DMA transfers. How would you possible intercept something
like that? True, you could use a non-present page region the same size
as your BAR, so that every access triggers a page fault that the
emulation driver could forward on to hardware, but the performance would
be absolutely hopeless, there’s no way you could handle a real-time
device, and you still have the problem of handling bus-mastering. Plus,
someone has to arbitrate the access so that the VMs don’t step on each
other.
No, virtualizing a PCI device is a very complicated task.
At least, I would expect that I was able to create a synthetic driver myself, so that the hardware is usable in a virtualized OS, or that the hardware could be assigned to a dedicated VM.
Assigning it to a dedicated VM might be possible. I’m not up-to-date on
the hypervisor options.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim,
DMA redirection aso, is indeed hard to implement, but Intel (and AMD also), are providing hardware support for virtualization: see http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf (see para 2.4)
With such hardware, a hypervisor CAN intercept I/O calls and redirect it to a VM.
I am no specialist in this matter as well, but as Hyper-V documentation is talking about emulated and synthetic devices, I thought it was possible for my device to be usable from a VM (iso the parent partition only).
What sort of device are we talking about? If it’s a storage or
networking device, then it is indirectly available within the VM,
though it is not exposed through your driver. Hyper-V provides a
networking switch that routes network traffic in and out of the VM,
and to your device.
If your device is of some other type, there is no opportunity in
Windows Server 2008’s Hyper-V to add support for it within a VM.
We’re honestly not ready to start treating our virtualization system
as a platform which others can build upon. We’ll get there, but not
until we’ve spent our engineering resources on the things that we can
accomplish directly.
–
Jake Oshins
Hyper-V I/O Architect
Microsoft
This post confers no rights and implies no warranties.
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I have a driver for a PCIe device, that is working on W2K8.
> I installed the hypervisor and an XP SP3 VM on it.
> When I go to the device manager in XP, my device is not listed.
> In W2K8 it is listed, the driver is installed and working.
>
> I’ve read somewhere about emulated/synthetic drivers, aso and was
> expecting for the device to become usable in the VM through some
> kind of synthetic driver.
>
> Is it possible to use custom hardware in a VM, and if so, are there
> any HW and/or driver requirements?
>
> Thanks
>
The Intel link that you site below is, indeed, what is necessary for
exposing a device directly within a VM. AMD has similar technology.
It’s important to note that neither Intel nor AMD have actually
shipped this yet. (Intel has actually shipped VT-d, though it’s VT-d2
which provides what we believe we need. VT-d2 has not shipped.) And
since the next version of Windows Server has already frozen from a
feature standpoint, we won’t be able to include this support in the
that release. Honestly, we wouldn’t have been able to spare the
resources to go to a full Direct I/O solution that soon even if these
hardware features were already available, as we’re still spending all
our energy on features that just missed the first Hyper-V release
(Live Migration, Dynamic Memory, network offloads, etc.) We’ll end up
doing this in some further release.
–
Jake Oshins
Hyper-V I/O Architect
Microsoft
This post confers no rights and implies no warranties.
wrote in message news:xxxxx@ntdev…
> Tim,
>
> DMA redirection aso, is indeed hard to implement, but Intel (and AMD
> also), are providing hardware support for virtualization: see
> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
> (see para 2.4)
> With such hardware, a hypervisor CAN intercept I/O calls and
> redirect it to a VM.
> I am no specialist in this matter as well, but as Hyper-V
> documentation is talking about emulated and synthetic devices, I
> thought it was possible for my device to be usable from a VM (iso
> the parent partition only).
>
It seems like you’ve got some confusion around terms. This is an easy
situation to get into, since every large company insists on using its
own terms for things. (This isn’t a practice that I really endorse,
but as a Microsoft employee, it’s simpler if I say “synthetic device”
rather than “paravirtualized device” though they mean the same thing.
Emulation and synthetic I/O are two different approaches. With
emulation, the operation is handled by a driver for a physical device
which doesn’t actually exist. Attempts to interact with the device
are intercepted by the hypervisor. At that point, nothing in the VM
has anything to do with what happens next. With synthetic drivers,
the native NT I/O stacks terminate at drivers which only load in VMs,
obviating the need for emulation and interception.
–
Jake Oshins
Hyper-V I/O Architect
Microsoft
This post confers no rights and implies no warranties.
wrote in message news:xxxxx@ntdev…
> Well, I would expect that the calls to the hardware are intercepted,
> redirected to the (synthetic) driver in the VM, which in it’s turn
> redirects it via the VMBus to the ‘real’ driver residing in the
> parent partition (W2K8). Because it is a PCIe device, I would expect
> that there would already be a (synthetic) driver capable of doing
> this.
> At least, I would expect that I was able to create a synthetic
> driver myself, so that the hardware is usable in a virtualized OS,
> or that the hardware could be assigned to a dedicated VM.
>
>
>
Out of curiosity, what does vt-d2 provide that is missing in vt-d that makes
io virtualization practical?
On Wed, Sep 10, 2008 at 4:12 PM, Jake Oshins wrote:
> The Intel link that you site below is, indeed, what is necessary for
> exposing a device directly within a VM. AMD has similar technology.
> It’s important to note that neither Intel nor AMD have actually
> shipped this yet. (Intel has actually shipped VT-d, though it’s VT-d2
> which provides what we believe we need. VT-d2 has not shipped.) And
> since the next version of Windows Server has already frozen from a
> feature standpoint, we won’t be able to include this support in the
> that release. Honestly, we wouldn’t have been able to spare the
> resources to go to a full Direct I/O solution that soon even if these
> hardware features were already available, as we’re still spending all
> our energy on features that just missed the first Hyper-V release
> (Live Migration, Dynamic Memory, network offloads, etc.) We’ll end up
> doing this in some further release.
>
> –
> Jake Oshins
> Hyper-V I/O Architect
> Microsoft
>
> This post confers no rights and implies no warranties.
> -------------------------
> wrote in message news:xxxxx@ntdev…
> > Tim,
> >
> > DMA redirection aso, is indeed hard to implement, but Intel (and AMD
> > also), are providing hardware support for virtualization: see
> >
> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
> > (see para 2.4)
> > With such hardware, a hypervisor CAN intercept I/O calls and
> > redirect it to a VM.
> > I am no specialist in this matter as well, but as Hyper-V
> > documentation is talking about emulated and synthetic devices, I
> > thought it was possible for my device to be usable from a VM (iso
> > the parent partition only).
> >
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
Interrupts. With VT-d, you can’t stop a device from generating any
arbitrary interrupt. With VT-d2, you get to provide fences that keep
a device from generating interrupts you don’t want to or can’t handle.
–
Jake Oshins
Hyper-V I/O Architect
Microsoft
This post confers no rights and implies no warranties.
“Mark Roddy” wrote in message
news:xxxxx@ntdev…
Out of curiosity, what does vt-d2 provide that is missing in vt-d that
makes io virtualization practical?
>… You don’t “call” into
hardware. To access a PCIe device, you read and write from
chunks of simulated memory, and some of those read and writes
might trigger things like bus-mastered DMA transfers. How
would you possible intercept something like that? True, you
could use a non-present page region the same size as your
BAR, so that every access triggers a page fault that the
emulation driver could forward on to hardware, but the
performance would be absolutely hopeless, there’s no way you
could handle a real-time device, and you still have the
problem of handling bus-mastering.
Many bus master devices use a chunk of common memory for an I/O queue, and
you only have to “touch” the actual hardware after reading/writing multiple
entries in a cached memory based queue. The overhead might not be so
drastic. When you touched the mailbox register page, the OS could trap to a
custom page fault handler or cause a hypervisor fault that signaled some
event in the parent partition thread (under Hyper-V)and it would “do the
right thing” with the entries in the queue. Overhead really might not be so
bad if when you touched the emulated mailbox register, a different processor
core did the emulation work. The other part of it is you need some way to
generate synthetic interrupts, either from outside the guest OS or if your
not in a VM, from some device emulation driver. The end performance would
depend a lot on the specific architecture of the device your simulating. Bit
banging I2C messages on a single bit register would be really painful,
signaling a very smart device with I/O queues would be a lot less painful.
Many bus mastering device are just running firmware with a path for shared
memory access. The mailbox register is actually just some memory accessable
to the firmware processor, which get’s polled when the firmware processor is
not busy doing something more important, like processing entries in the I/O
queues.
Even if performance was unimpressive, being able to write a simulated device
would often be very worthwhile, so you can write the drivers while the
actual hardware is being developed. Of course adding emulated devices to a
production OS like Windows might not be justified, and you should just run
Windows in a VM controlled by some kitchen sink OS that can cater to
specialized features. Or maybe there should be the Windows kitchen sink
edition just for people who have a special need which the normal millions
and millions of Windows systems don’t need.
Jan
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3433 (20080910) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Jake Oshins wrote:
If your device is of some other type, there is no opportunity in
Windows Server 2008’s Hyper-V to add support for it within a VM.
We’re honestly not ready to start treating our virtualization system
as a platform which others can build upon. We’ll get there, but not
until we’ve spent our engineering resources on the things that we can
accomplish directly.
So we aren’t up to some groundbreaking surprise next week. Thanks, this
is good news 
–PA
Is there any chance for Microsoft to implement custom Hyper-V SCSI providers inside parent partition for any virtual IDE/SCSI device in VM?
Once such provider is registered Hyper-V could display it in VM settings as another option besides
standard Image or “pass-through to physical device” media options - in fact type of device would be determined by provider DLL which would process all standard SCSI requests like INQUIRY. MODE SENSE etc.
Such approach could creage huge advantages and flexibility:
- Vendors could implement virtual device of any complexity and type and inject it to guest VM: disks, worms, magneto-optical, tapes etc. The only requirement for them would be to support SCSI protocol. All logical functionality would be inside provider DLL.
2)In opposite to normal pass-through such emulated device does not need to exist in parent partition - it would be fully synthetical and its behavior would be governed solely by provider.
3)Such approach could greatly assist to manufacturers of custom storage devices - they can port device firmware to such DLL and perform any device debugging and testing inside VM without having to deal with real hardware.
Microsoft is doing big job with Hyper-V - let’s hope they have time to think about such idea.