WinHV WDK Library

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
>

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
>>
>
>
>
>

> 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

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?

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

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

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.

Yes, the WinHV.sys is in %windir%\system32\drivers and I have two guest OS (WinXP and Vista) running.

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.

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
>>>
>>
>>
>>
>>
>
>
>

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.

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.
>

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

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

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

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

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

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.

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
>
>

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