Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Extending Virtualization (was PCI Device Simulation)

Jake_OshinsJake_Oshins Member Posts: 1,058
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" <xxxxx@valhallalegends.com> 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 <xxxxx@windows.microsoft.com>
Sent: Wednesday, October 08, 2008 18:30
To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
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" <xxxxx@gmail.com> 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

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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.
  • Ken_JohnsonKen_Johnson Member - All Emails Posts: 1,559
    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. :)

    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" <xxxxx@valhallalegends.com> 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 <xxxxx@windows.microsoft.com>
    Sent: Wednesday, October 08, 2008 18:30
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    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" <xxxxx@gmail.com> 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
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    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" <xxxxx@valhallalegends.com> 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. :)

    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" <xxxxx@valhallalegends.com> 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 <xxxxx@windows.microsoft.com>
    Sent: Wednesday, October 08, 2008 18:30
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    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" <xxxxx@gmail.com> 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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space