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

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

WinHV WDK Library

HY_YangHY_Yang Member Posts: 12
Hi,

Does anyone know where is the WinHV library? I am exploring the WinHV C function interface. I can find the WinHV header file but couldn't find the library to link with my driver. The WDK I am using is release 6001.18001. Thanks!

HY

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,307
    the interfaces are implemented by winhv.sys.

    On Thu, May 29, 2008 at 4:32 PM, wrote:

    > Hi,
    >
    > Does anyone know where is the WinHV library? I am exploring the WinHV C
    > function interface. I can find the WinHV header file but couldn't find the
    > library to link with my driver. The WDK I am using is release 6001.18001.
    > Thanks!
    >
    > HY
    >
    > ---
    > 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
  • HY_YangHY_Yang Member Posts: 12
    Yes, I have read that the C interfaces are in winhv.sys. But, how to call the C interfaces from other driver? Is there any doc. about using kernel dll for 64bits Vista somewhere?

    HY
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    What is it you want to do with WinHv? I have no idea where you get
    the lib to link against. I assume it will come in some kit somewhere.
    But I'm curious what you think it will get you.

    I'm of the opinion that WinHv doesn't do much for you at all, as it's
    just a wrapper around the hypercall interface. And the hypercall
    interface only really does two things for you. It allows you to
    figure out how to run Windows Server 2008 on top of your non-Microsoft
    hypervisor (because you know what it expects to call) or it allows you
    to figure out how to make a non-Windows OS run well on top of a
    Microsoft hypervisor (Hyper-V, which is in Server 2008.)

    Linking against WinHv doesn't really help you in either case. If
    you're implementing a non-Microsoft hypervisor, then it's unlikely
    you're going to use a hypercall wrapper that's delivered as a Windows
    driver. In fact, it's unlikely that you're going to use a hypercall
    wrapper at all. If you're implementing a non-Windows OS and trying to
    get it to run on Hyper-V, then you again probably have no use for a
    wrapper delivered as a Windows driver.

    - Jake Oshins
    Hyper-V I/O Architect
    (implementer of quite a bit of code that invokes WinHv)


    wrote in message news:xxxxx@ntdev...
    > Yes, I have read that the C interfaces are in winhv.sys. But, how to
    > call the C interfaces from other driver? Is there any doc. about
    > using kernel dll for 64bits Vista somewhere?
    >
    > HY
    >
  • HY_YangHY_Yang Member Posts: 12
    Hi Jake,

    Thanks for your opinion. What I want to do is exploring the inter-partition communication for my company's future product. The WinHV service management functions looks suitable for the job. If MSFT haven't release the WinHV library at this point, what alternative do I have?

    HY
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,307
    Actually there are of course good reasons why one might want to use these
    interfaces, and it is odd that the WDK documents them but appears to not
    include the .lib file to link against.

    On Sat, May 31, 2008 at 1:43 AM, wrote:

    > Hi Jake,
    >
    > Thanks for your opinion. What I want to do is exploring the inter-partition
    > communication for my company's future product. The WinHV service management
    > functions looks suitable for the job. If MSFT haven't release the WinHV
    > library at this point, what alternative do I have?
    >
    > HY
    >
    > ---
    > 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Pretty much, although I'm not sure I'd agree with the part about it being 'odd.' Maybe winhv.lib is wherever the CHK build of S2008 is?


    mm



    Mark Roddy wrote:
    > Actually there are of course good reasons why one might want to use
    > these interfaces, and it is odd that the WDK documents them but appears
    > to not include the .lib file to link against.
    >
    > On Sat, May 31, 2008 at 1:43 AM, <mailto:xxxxx@gmail.com>> wrote:
    >
    > Hi Jake,
    >
    > Thanks for your opinion. What I want to do is exploring the
    > inter-partition communication for my company's future product. The
    > WinHV service management functions looks suitable for the job. If
    > MSFT haven't release the WinHV library at this point, what
    > alternative do I have?
    >
    > HY
    >
    > ---
    > 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Well, I suppose that your only real option here is to create your own import library, which fortunately isn't all that difficult.

    Roughly:

    1. dumpbin /exports winhv.sys

    2. create a .def file using this information that looks something like this:

    LIBRARY winhv
    EXPORT
    <function 1>
    <function 2>

    3. create and import library with LIB /DEF:winhv.def /OUT:winhv.lib

    Or something like that. It's been a long time since I've needed to resort to something quite this silly, but I don't see what other
    choice you have here, if you want to use WinHV. In particular, the syntax of the of .DEF file may not be exactly correct, and I'm
    not sure about the LIB command line either, but this is the general idea. Also, I don't believe that I've ever tried this method
    with something in the kernel, though I can't think of any reason why this would make any difference.

    I don't have any idea of what the deal with winhv.lib is (why it's MIA from the WDK, that is), but I wouldn't hold my breath while
    waiting for it to appear. As Mickey Mouse and low rent as it would be to intentionally exclude it, only so many things can go
    missing or experience technical difficulties, and either way, they don't seem to appear after the issue is acknowledged, which is
    really the only thing that matters for the purpose of planning, so were I you, that would be my working assumption.


    Good luck,

    mm

    xxxxx@gmail.com wrote:
    > Hi Jake,
    >
    > Thanks for your opinion. What I want to do is exploring the inter-partition communication for my company's future product. The WinHV service management functions looks suitable for the job. If MSFT haven't release the WinHV library at this point, what alternative do I have?
    >
    > HY
    >
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    Even with WinHv, you don't get useful inter-partition communication.
    Since virtual machine state management for Hyper-V isn't within the
    hypervisor itself, (it's in the parent partition,) merely hooking into
    the hypervisor won't allow you to integrate with VM
    save/snapshot/migration operations. Without these, the VM is largely
    crippled. So even if you build your own inter-partition
    communications using the hypervisor, you end up with a system that's a
    lot less than usable.

    - Jake Oshins


    wrote in message news:xxxxx@ntdev...
    > Hi Jake,
    >
    > Thanks for your opinion. What I want to do is exploring the
    > inter-partition communication for my company's future product. The
    > WinHV service management functions looks suitable for the job. If
    > MSFT haven't release the WinHV library at this point, what
    > alternative do I have?
    >
    > HY
    >
  • HY_YangHY_Yang Member Posts: 12
    Hi mm,

    Using this method I can create the .lib and link with the driver. However,
    the Server 2008 give me "The driver may be corrupted or missing. (Code 39)"
    error while loading the driver. I guess I just have to wait for MSFT release
    the lib or go for the native hypercall. Thanks for tip.

    HY


    "Martin O'Brien" wrote in message
    news:xxxxx@ntdev...
    > Well, I suppose that your only real option here is to create your own
    > import library, which fortunately isn't all that difficult.
    >
    > Roughly:
    >
    > 1. dumpbin /exports winhv.sys
    >
    > 2. create a .def file using this information that looks something like
    > this:
    >
    > LIBRARY winhv
    > EXPORT
    >
    >
    >
    > 3. create and import library with LIB /DEF:winhv.def /OUT:winhv.lib
    >
    > Or something like that. It's been a long time since I've needed to resort
    > to something quite this silly, but I don't see what other choice you have
    > here, if you want to use WinHV. In particular, the syntax of the of .DEF
    > file may not be exactly correct, and I'm not sure about the LIB command
    > line either, but this is the general idea. Also, I don't believe that
    > I've ever tried this method with something in the kernel, though I can't
    > think of any reason why this would make any difference.
    >
    > I don't have any idea of what the deal with winhv.lib is (why it's MIA
    > from the WDK, that is), but I wouldn't hold my breath while waiting for it
    > to appear. As Mickey Mouse and low rent as it would be to intentionally
    > exclude it, only so many things can go missing or experience technical
    > difficulties, and either way, they don't seem to appear after the issue is
    > acknowledged, which is really the only thing that matters for the purpose
    > of planning, so were I you, that would be my working assumption.
    >
    >
    > Good luck,
    >
    > mm
    >
    > xxxxx@gmail.com wrote:
    >> Hi Jake,
    >>
    >> Thanks for your opinion. What I want to do is exploring the
    >> inter-partition communication for my company's future product. The WinHV
    >> service management functions looks suitable for the job. If MSFT haven't
    >> release the WinHV library at this point, what alternative do I have?
    >>
    >> HY
    >
  • HY_YangHY_Yang Member Posts: 12
    Hi Jake,

    I understand the VM save/snapshot/migration is going to be the problem needs
    to be solved. At this stage we just like to explore the capability of
    inter-partition communication and share memory between partitions.

    Since WDK documents the WinHV interface, I guess MSFT should have the plan
    to release the Hyper-V development kit. Any ideal of the release date?
    Thanks.

    HY


    "Jake Oshins" wrote in message
    news:xxxxx@ntdev...
    > Even with WinHv, you don't get useful inter-partition communication. Since
    > virtual machine state management for Hyper-V isn't within the hypervisor
    > itself, (it's in the parent partition,) merely hooking into the hypervisor
    > won't allow you to integrate with VM save/snapshot/migration operations.
    > Without these, the VM is largely crippled. So even if you build your own
    > inter-partition communications using the hypervisor, you end up with a
    > system that's a lot less than usable.
    >
    > - Jake Oshins
    >
    >
    > wrote in message news:xxxxx@ntdev...
    >> Hi Jake,
    >>
    >> Thanks for your opinion. What I want to do is exploring the
    >> inter-partition communication for my company's future product. The WinHV
    >> service management functions looks suitable for the job. If MSFT haven't
    >> release the WinHV library at this point, what alternative do I have?
    >>
    >> HY
    >>
    >
    >
    >
    >
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > the Server 2008 give me "The driver may be corrupted or missing. (Code 39)"

    Lack of signature?

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    xxxxx@storagecraft.com
    http://www.storagecraft.com
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Yeah, I think that's a signing error. It certainly isn't a lib issue.

    mm

    Maxim S. Shatskih wrote:
    >> the Server 2008 give me "The driver may be corrupted or missing. (Code 39)"
    >
    > Lack of signature?
    >
  • HY_YangHY_Yang Member Posts: 12
    My driver works fine before link with the lib. I also tried to disable the driver signature enforcement (by F8 key) and got the same error.

    HY
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,438
    Silly question...are you sure winhv.sys is in %windir%\system32\drivers on your target system?

    -----Original Message-----
    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
    Sent: Tuesday, June 03, 2008 10:08 AM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] WinHV WDK Library

    My driver works fine before link with the lib. I also tried to disable the driver signature enforcement (by F8 key) and got the same error.

    HY

    ---
    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
    d
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,035
    xxxxx@gmail.com wrote:
    > My driver works fine before link with the lib. I also tried to disable the driver signature enforcement (by F8 key) and got the same error.
    >

    Is winhv.sys really installed on your operating system? Is the
    Hypervisor running?

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • HY_YangHY_Yang Member Posts: 12
    Yes, the WinHV.sys is in %windir%\system32\drivers and I have two guest OS (WinXP and Vista) running.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,035
    xxxxx@gmail.com wrote:
    > Yes, the WinHV.sys is in %windir%\system32\drivers and I have two guest OS (WinXP and Vista) running.
    >

    In the "grasping at straws" phase now, can you do a "link /dump /exports
    %windir%\system32\drivers\winhv.sys" and make sure the entry points you
    want are exported? I don't know how many versions of winhv.sys there
    have been.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Jake_OshinsJake_Oshins Member Posts: 1,058
    I don't think that there's any kit in plan.

    You'll be able to create cross-paritition communication. I know
    because that's exactly what I've done. What you won't be able to do
    is get to the next stage where that works with VM state changes.

    - Jake Oshins


    "HY Yang" wrote in message news:xxxxx@ntdev...
    > Hi Jake,
    >
    > I understand the VM save/snapshot/migration is going to be the
    > problem needs to be solved. At this stage we just like to explore
    > the capability of inter-partition communication and share memory
    > between partitions.
    >
    > Since WDK documents the WinHV interface, I guess MSFT should have
    > the plan to release the Hyper-V development kit. Any ideal of the
    > release date? Thanks.
    >
    > HY
    >
    >
    > "Jake Oshins" wrote in message
    > news:xxxxx@ntdev...
    >> Even with WinHv, you don't get useful inter-partition
    >> communication. Since virtual machine state management for Hyper-V
    >> isn't within the hypervisor itself, (it's in the parent partition,)
    >> merely hooking into the hypervisor won't allow you to integrate
    >> with VM save/snapshot/migration operations. Without these, the VM
    >> is largely crippled. So even if you build your own inter-partition
    >> communications using the hypervisor, you end up with a system
    >> that's a lot less than usable.
    >>
    >> - Jake Oshins
    >>
    >>
    >> wrote in message news:xxxxx@ntdev...
    >>> Hi Jake,
    >>>
    >>> Thanks for your opinion. What I want to do is exploring the
    >>> inter-partition communication for my company's future product. The
    >>> WinHV service management functions looks suitable for the job. If
    >>> MSFT haven't release the WinHV library at this point, what
    >>> alternative do I have?
    >>>
    >>> HY
    >>>
    >>
    >>
    >>
    >>
    >
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hi Jake,

    Regarding the 'kit' availability, if there will be no such release, do you know how IHVs will support their products under Server 2008/Hyper-V? That is, IHVs outside of those such as NIC and HBA?

    Reading various bits of documentation, I was under the impression there would be a DDK to allow IHVs to create 'enlightened' interfaces to guest VMs via VMBus/WinHV, moving data into the Server 2008 root partition to native hardware drivers.
  • Jake_OshinsJake_Oshins Member Posts: 1,058
    They won't. We simply weren't able to make Hyper-V a platform for
    others to build on in the first release. We will probably do that
    some day, but not right now.

    The design goal for Server 2008 Hyper-V was to use existing Windows
    device drivers without modification. This necessitated a strategy
    where we have one copy of Windows that owns all the I/O devices in the
    system and every VM sees a completely idealized view of the system,
    with no visible features of the underlying hardware leaking through.
    I think we did relatively well at that, and the I/O performance is
    frankly better than I once thought it could be with that approach.
    (You're wecome to see for yourselves if you're downloading the latest
    release candidates.)

    We will gradually open up the virtualization space so that it truly is
    a platform. I expect that we'll start by making the networking and
    storage stacks more aware of virtualization, as they are still our
    major I/O bottlenecks. After that, we'll look more widely.

    - Jake Oshins
    Hyper-V I/O Architect


    wrote in message news:xxxxx@ntdev...
    > Hi Jake,
    >
    > Regarding the 'kit' availability, if there will be no such release,
    > do you know how IHVs will support their products under Server
    > 2008/Hyper-V? That is, IHVs outside of those such as NIC and HBA?
    >
    > Reading various bits of documentation, I was under the impression
    > there would be a DDK to allow IHVs to create 'enlightened'
    > interfaces to guest VMs via VMBus/WinHV, moving data into the Server
    > 2008 root partition to native hardware drivers.
    >
  • Chengwei_LinChengwei_Lin Member Posts: 7
    Hi, all,

    Just to let you know that I followed MM's instruction and successfully built a WinHv.lib which links successfully with my driver. Now my (test-signed) driver can load on Windows server 2008 and call the hypercall (e.g. WinHvGetIdentifierString) without problem.

    My target is also to make the inter-partition communication work. So my next tries would be WinHvCreatePort/WinHvConnectPort/WinHvPostMessage/WinHvSignalEvent etc.

    Thanks a lot for you guys' helpful hint. I appreciate that.

    Best regards,
    Chengwei
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    This is remarkably silly. Microsoft has published the interfaces but not
    the .lib file and developers with good intentions are off doing
    miserable hackery in order to get their stuff working, as they have no
    other choice.


    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of
    xxxxx@tpemail.net.tw
    Sent: Thursday, June 05, 2008 6:42 AM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] WinHV WDK Library

    Hi, all,

    Just to let you know that I followed MM's instruction and successfully
    built a WinHv.lib which links successfully with my driver. Now my
    (test-signed) driver can load on Windows server 2008 and call the
    hypercall (e.g. WinHvGetIdentifierString) without problem.

    My target is also to make the inter-partition communication work. So my
    next tries would be
    WinHvCreatePort/WinHvConnectPort/WinHvPostMessage/WinHvSignalEvent etc.

    Thanks a lot for you guys' helpful hint. I appreciate that.

    Best regards,
    Chengwei

    ---
    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
    Yup. I agree completely. The published interfaces will disappear in
    the next documentation drop.

    Since there is not really anything you could build with them that will
    work end-to-end, publishing them doesn't help anyone.

    - Jake Oshins



    "Roddy, Mark" wrote in message
    news:xxxxx@ntdev...
    This is remarkably silly. Microsoft has published the interfaces but
    not
    the .lib file and developers with good intentions are off doing
    miserable hackery in order to get their stuff working, as they have no
    other choice.


    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of
    xxxxx@tpemail.net.tw
    Sent: Thursday, June 05, 2008 6:42 AM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] WinHV WDK Library

    Hi, all,

    Just to let you know that I followed MM's instruction and successfully
    built a WinHv.lib which links successfully with my driver. Now my
    (test-signed) driver can load on Windows server 2008 and call the
    hypercall (e.g. WinHvGetIdentifierString) without problem.

    My target is also to make the inter-partition communication work. So
    my
    next tries would be
    WinHvCreatePort/WinHvConnectPort/WinHvPostMessage/WinHvSignalEvent
    etc.

    Thanks a lot for you guys' helpful hint. I appreciate that.

    Best regards,
    Chengwei

    ---
    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_RoddyMark_Roddy Member - All Emails Posts: 4,307
    Well that is one solution. Putting the toothpaste back in the tube never
    works very well.

    On Thu, Jun 5, 2008 at 2:17 PM, Jake Oshins
    wrote:

    > Yup. I agree completely. The published interfaces will disappear in
    > the next documentation drop.
    >
    > Since there is not really anything you could build with them that will
    > work end-to-end, publishing them doesn't help anyone.
    >
    > - Jake Oshins
    >
    >
    >
    > "Roddy, Mark" wrote in message
    > news:xxxxx@ntdev...
    > This is remarkably silly. Microsoft has published the interfaces but
    > not
    > the .lib file and developers with good intentions are off doing
    > miserable hackery in order to get their stuff working, as they have no
    > other choice.
    >
    >
    > -----Original Message-----
    > From: xxxxx@lists.osr.com
    > [mailto:xxxxx@lists.osr.com] On Behalf Of
    > xxxxx@tpemail.net.tw
    > Sent: Thursday, June 05, 2008 6:42 AM
    > To: Windows System Software Devs Interest List
    > Subject: RE:[ntdev] WinHV WDK Library
    >
    > Hi, all,
    >
    > Just to let you know that I followed MM's instruction and successfully
    > built a WinHv.lib which links successfully with my driver. Now my
    > (test-signed) driver can load on Windows server 2008 and call the
    > hypercall (e.g. WinHvGetIdentifierString) without problem.
    >
    > My target is also to make the inter-partition communication work. So
    > my
    > next tries would be
    > WinHvCreatePort/WinHvConnectPort/WinHvPostMessage/WinHvSignalEvent
    > etc.
    >
    > Thanks a lot for you guys' helpful hint. I appreciate that.
    >
    > Best regards,
    > Chengwei
    >
    > ---
    > 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
    >



    --
    Mark Roddy
  • Chengwei_LinChengwei_Lin Member Posts: 7
    Hi, Jake,

    I have question about you mentioning "there is not really anything you could build with them that will work end-to-end". May I have some clarification?

    What I'm doing now is NOT related to either of the two things you mentioned in previous reply - i.e. I'm neither trying to run Win 2k8 on non-MS hypervisor, nor to run non-Windows OS on MS hypervisor. What I'm doing is just an application with some kernel drivers running in the guest OSs. Among others, one scenario is I need to be able to communicate between partitions when the partitions are intentionally network disabled (probably for security reason). In that case, inter-partition communication hypercalls seems to be the only way I can use.

    Of course inter-partition calls is just an example. What I mean is, even though we are not hypervisor or guest OS developers, hypercalls is still of great values for us as application and driver developers and we do need it.

    This is my thoughts. Thanks!

    Best regards,
    Chengwei
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,035
    xxxxx@tpemail.net.tw wrote:
    > I have question about you mentioning "there is not really anything you could build with them that will work end-to-end". May I have some clarification?
    > ...
    > Of course inter-partition calls is just an example. What I mean is, even though we are not hypervisor or guest OS developers, hypercalls is still of great values for us as application and driver developers and we do need it.
    >

    I believe that last paragraph is EXACTLY the assertion that Jake was
    challenging. There are no good, compelling scenarios where this is
    useful. Fun to play with? Maybe. Productive and useful? Very doubtful.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Jake_OshinsJake_Oshins Member Posts: 1,058
    The Microsoft hypervisor is not integrated with much of the state of
    the VM. That lives in the virtualization stack in the parent
    partition. The hypervisor itself is a microkernel that manages
    address translations, interrupt delivery and virtual processor
    scheduling. As such, you can't know just by interacting with the
    hypervisor when the VM is paused, saved, migrated or snapshotted. You
    also can't know when the address map of the VM changes.

    So, while you might use hypercalls to send a message or two back and
    forth, you might lose messages when the partition is saved. If you
    try to describe memory buffers, the addresses of those buffers can
    change without notice. If you try to send interrupts, they might be
    dropped.

    Imagine trying to deliver a product to customers just to get a call
    from them saying that it hung or crashed as soon as they pushed the
    "snapshot" button in the Hyper-V Manager.

    This is why I say that you really can't build much with just the
    hypercall interface. You need integration with the virtualization
    stack, which we're not yet providing. When we think that we can
    support it as a platform, we probably will provide exactly that.

    However, at the point that we make Hyper-V a platform, you'll probably
    also get the VMBus layer, which will be far more useful than the
    hypercall interface.

    - Jake Oshins
    Hyper-V I/O Architect


    wrote in message news:xxxxx@ntdev...
    > Hi, Jake,
    >
    > I have question about you mentioning "there is not really anything
    > you could build with them that will work end-to-end". May I have
    > some clarification?
    >
    > What I'm doing now is NOT related to either of the two things you
    > mentioned in previous reply - i.e. I'm neither trying to run Win 2k8
    > on non-MS hypervisor, nor to run non-Windows OS on MS hypervisor.
    > What I'm doing is just an application with some kernel drivers
    > running in the guest OSs. Among others, one scenario is I need to be
    > able to communicate between partitions when the partitions are
    > intentionally network disabled (probably for security reason). In
    > that case, inter-partition communication hypercalls seems to be the
    > only way I can use.
    >
    > Of course inter-partition calls is just an example. What I mean is,
    > even though we are not hypervisor or guest OS developers, hypercalls
    > is still of great values for us as application and driver developers
    > and we do need it.
    >
    > This is my thoughts. Thanks!
    >
    > Best regards,
    > Chengwei
    >
    >
  • Chengwei_LinChengwei_Lin Member Posts: 7
    Hi, Jake,

    Thanks a lot for your detailed explanation. I think I have much clearer understanding about the design philosophy behind Windows hypervisor now.

    So it sounds like it is the virtualization stack, and probably the VMBus, that we should be utilizing for cross-partition talk and/or other VM management, so as to be "VM state-safe". Right?

    Okay. If that's the case, then I think what I can do now may just be waiting. But before MS could officially provides that platform, I might just play around the hypercalls for some more experiments.


    Thank you.

    Best regards,
    Chengwei
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
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA