Extending Virtualization (was PCI Device Simulation)

Interesting examples you picked…

If we opened up VMBus, we’d still need to open up the debugger transports
before you’d get to replace the emulated COM port. Furthermore, VMBus is
the wrong abstraction for debugging. Debugging data should be passed
directly through the hypervisor so that you don’t need to wait until
vmbus.sys loads before debugging works (or, alternatively, build an
implementation of VMBus into the debugging transport DLL.) That’s something
that’s on my list to do anyhow. We got most of the way through it and cut
the feature in order to get the software out the door.

Futhermore, opening up VMBus wouldn’t do anything for the guy who started
this thread. With that said, I agree. We’ll open VMBus as soon as we can
effectively test the API. For Windows Server 2008 Hyper-V (and 2008 R2) we
simply didn’t have the time to bring it to a level that we can support for
the next 15 years, which is the requirement.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.


“Skywing” wrote in message
news:xxxxx@ntdev…
Still, opening VMBus itself could have interesting possibilities, like
replacing the bit-banging COM port with something modern for fast kd, though
requiring signed kd transport modules is a downer on that particular
example.

I know that I’d love to be able to write VMBus clients && host-side service
providers without having to fire upye olde disassembler, though.

It does seem more sensible to go that route than to open up legacy device
emulation, or so I would think, anyways.

- S

-----Original Message-----
From: xxxxx@windows.microsoft.com
Sent: Wednesday, October 08, 2008 18:30
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PCI Device Simulation

Such a thing is certainly possible, though we don’t publish interfaces for
you to do this with Virtual PC, Virtual Server or Hyper-V. Honestly, if we
did, we’d have to change our motherboard emulation to something a little
more modern so that you’d get support for things like PCI-Express. We have
no intention of doing that, as the old motherboard is useful for running old
OSes in a VM. Maybe VMWare publishes their interfaces. I don’t know.

Without a VM, simulation will necessarily have holes in it, which is why DSF
is imcomplete in this regard and why most recommendations will be for your
to recompile your driver with stubs in place of the functions which
manipulate hardware.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.
“Oren Weil” wrote in message news:xxxxx@ntdev…
> Hello
>
> Is there a way to Simulate PCI Device By using something like DSF or by
> using Virtual Machine (VMWare, VirtualPC and etc…) or by something else?
>
> Thanks in Advance.
>
>
> –
> Oren
>


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

I was personally hoping that you’d open the upper edge bus interface. That way I could write my ViBus to fully encapsulate the complexity of talking to xen while exposing the same interface. Then all of the Microsoft virtualized devices could sit on a ViBus as easily as a VMBus - assuming your architecture is such that you don’t do hypercalls or specific IO in the devices.

Yeah, you wouldn’t want the debugger transport to depend on VMBus.sys. I suppose I should have clarified that, in that it’d be nice to be able to use the hypercalls that VMBus uses to talk to the host-side infrastructure, rather than the debugger being a guest-side client of VMBus.

I would argue that it’s better done like that than having the (IMO) a bit on the sleazy side hypercall that’s the hint about polling for debug data which exists right now, as the hypervisor itself doesn’t need to have any visibility into the debugger, just act as a data transport for it.

So, I’ll take a stab at restating those thoughts a lil bit:

  1. Suggest opening up the host-side interface that the various communication hypercalls go to, as the hypercalls are already documented, just not their usage and how to interact with them host-side. Along with this, document the underlying protocol for using the communication hypercalls to talk with host-side things.
  2. Suggest opening up VMBus and the host-side interface for VMBus. I’m assuming that all of this stuff internally builds on top off the stuff mentioned in 1) as a client of that. I certainly agree that the debugger transport would be much better situated as a “raw client” than a user of the “cooked” view that VMBus (probably) provides, for layering reasons.

I picked the debugger transport example as it’s a bit near and dear to my heart, having, erm, poked at it a bit with respect to VMware some time ago. But there’s value (IMO) to opening both levels of that up, though VMBus is likely more generally applicable.

The fact that you’re working on at least some of this stuff (and have some of the other things considered as nice to haves) is definitely encouraging, though. :slight_smile:

And, yeah, this wouldn’t help the OP simulate a PCI device. Seemed like a good moment to hijack the thread for a brief time, though; apologies to the OP on that front.

  • S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Thursday, October 09, 2008 1:37 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Extending Virtualization (was PCI Device Simulation)

Interesting examples you picked…

If we opened up VMBus, we’d still need to open up the debugger transports
before you’d get to replace the emulated COM port. Furthermore, VMBus is
the wrong abstraction for debugging. Debugging data should be passed
directly through the hypervisor so that you don’t need to wait until
vmbus.sys loads before debugging works (or, alternatively, build an
implementation of VMBus into the debugging transport DLL.) That’s something
that’s on my list to do anyhow. We got most of the way through it and cut
the feature in order to get the software out the door.

Futhermore, opening up VMBus wouldn’t do anything for the guy who started
this thread. With that said, I agree. We’ll open VMBus as soon as we can
effectively test the API. For Windows Server 2008 Hyper-V (and 2008 R2) we
simply didn’t have the time to bring it to a level that we can support for
the next 15 years, which is the requirement.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.


“Skywing” wrote in message
news:xxxxx@ntdev…
Still, opening VMBus itself could have interesting possibilities, like
replacing the bit-banging COM port with something modern for fast kd, though
requiring signed kd transport modules is a downer on that particular
example.

I know that I’d love to be able to write VMBus clients && host-side service
providers without having to fire upye olde disassembler, though.

It does seem more sensible to go that route than to open up legacy device
emulation, or so I would think, anyways.

- S

-----Original Message-----
From: xxxxx@windows.microsoft.com
Sent: Wednesday, October 08, 2008 18:30
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PCI Device Simulation

Such a thing is certainly possible, though we don’t publish interfaces for
you to do this with Virtual PC, Virtual Server or Hyper-V. Honestly, if we
did, we’d have to change our motherboard emulation to something a little
more modern so that you’d get support for things like PCI-Express. We have
no intention of doing that, as the old motherboard is useful for running old
OSes in a VM. Maybe VMWare publishes their interfaces. I don’t know.

Without a VM, simulation will necessarily have holes in it, which is why DSF
is imcomplete in this regard and why most recommendations will be for your
to recompile your driver with stubs in place of the functions which
manipulate hardware.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.
“Oren Weil” wrote in message news:xxxxx@ntdev…
> Hello
>
> Is there a way to Simulate PCI Device By using something like DSF or by
> using Virtual Machine (VMWare, VirtualPC and etc…) or by something else?
>
> Thanks in Advance.
>
>
> –
> Oren
>


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


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

We understand what you’re saying. We’ll do that some day. At the moment,
though, we’re spending all of our engineering and test resources on making a
product which is all that it can be without trying to also be a platform.
We honestly have a huge number of things that we can do on our own to
improve a lot of issues, and at this point, we can’t afford the distraction
of supporting an API. This will change.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.


“Skywing” wrote in message
news:xxxxx@ntdev…
Yeah, you wouldn’t want the debugger transport to depend on VMBus.sys. I
suppose I should have clarified that, in that it’d be nice to be able to use
the hypercalls that VMBus uses to talk to the host-side infrastructure,
rather than the debugger being a guest-side client of VMBus.

I would argue that it’s better done like that than having the (IMO) a bit on
the sleazy side hypercall that’s the hint about polling for debug data which
exists right now, as the hypervisor itself doesn’t need to have any
visibility into the debugger, just act as a data transport for it.

So, I’ll take a stab at restating those thoughts a lil bit:

1) Suggest opening up the host-side interface that the various communication
hypercalls go to, as the hypercalls are already documented, just not their
usage and how to interact with them host-side. Along with this, document
the underlying protocol for using the communication hypercalls to talk with
host-side things.
2) Suggest opening up VMBus and the host-side interface for VMBus. I’m
assuming that all of this stuff internally builds on top off the stuff
mentioned in 1) as a client of that. I certainly agree that the debugger
transport would be much better situated as a “raw client” than a user of the
“cooked” view that VMBus (probably) provides, for layering reasons.

I picked the debugger transport example as it’s a bit near and dear to my
heart, having, erm, poked at it a bit with respect to VMware some time ago.
But there’s value (IMO) to opening both levels of that up, though VMBus is
likely more generally applicable.

The fact that you’re working on at least some of this stuff (and have some
of the other things considered as nice to haves) is definitely encouraging,
though. :slight_smile:

And, yeah, this wouldn’t help the OP simulate a PCI device. Seemed like a
good moment to hijack the thread for a brief time, though; apologies to the
OP on that front.

- S

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jake Oshins
Sent: Thursday, October 09, 2008 1:37 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Extending Virtualization (was PCI Device Simulation)

Interesting examples you picked…

If we opened up VMBus, we’d still need to open up the debugger transports
before you’d get to replace the emulated COM port. Furthermore, VMBus is
the wrong abstraction for debugging. Debugging data should be passed
directly through the hypervisor so that you don’t need to wait until
vmbus.sys loads before debugging works (or, alternatively, build an
implementation of VMBus into the debugging transport DLL.) That’s something
that’s on my list to do anyhow. We got most of the way through it and cut
the feature in order to get the software out the door.

Futhermore, opening up VMBus wouldn’t do anything for the guy who started
this thread. With that said, I agree. We’ll open VMBus as soon as we can
effectively test the API. For Windows Server 2008 Hyper-V (and 2008 R2) we
simply didn’t have the time to bring it to a level that we can support for
the next 15 years, which is the requirement.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.

--------------------------------------------
“Skywing” wrote in message
news:xxxxx@ntdev…
Still, opening VMBus itself could have interesting possibilities, like
replacing the bit-banging COM port with something modern for fast kd, though
requiring signed kd transport modules is a downer on that particular
example.

I know that I’d love to be able to write VMBus clients && host-side service
providers without having to fire upye olde disassembler, though.

It does seem more sensible to go that route than to open up legacy device
emulation, or so I would think, anyways.

- S

-----Original Message-----
From: xxxxx@windows.microsoft.com
Sent: Wednesday, October 08, 2008 18:30
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] PCI Device Simulation

Such a thing is certainly possible, though we don’t publish interfaces for
you to do this with Virtual PC, Virtual Server or Hyper-V. Honestly, if we
did, we’d have to change our motherboard emulation to something a little
more modern so that you’d get support for things like PCI-Express. We have
no intention of doing that, as the old motherboard is useful for running old
OSes in a VM. Maybe VMWare publishes their interfaces. I don’t know.

Without a VM, simulation will necessarily have holes in it, which is why DSF
is imcomplete in this regard and why most recommendations will be for your
to recompile your driver with stubs in place of the functions which
manipulate hardware.


Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team

This post implies no warranties and confers no rights.
“Oren Weil” wrote in message news:xxxxx@ntdev…
> Hello
>
> Is there a way to Simulate PCI Device By using something like DSF or by
> using Virtual Machine (VMWare, VirtualPC and etc…) or by something else?
>
> Thanks in Advance.
>
>
> –
> Oren
>


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


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