> On 15 Oct 2017, at 15:21, ge...@hostfission.com wrote: > > Hi Yan, > > Thank you for the information. I am rather new to Windows Driver development > and learning as I go, so this may take some time, but since the driver only > needs to perform very basic functions I do not see this as being too much of > a challenge.
I think you can look into Windows virtio-balloon implementation as an example of simple driver: https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/Balloon It relies on virtio library (https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/VirtIO) and it is WDF driver (MS framework that simplifies the drivers development) that makes it very simple. > > -Geoff > > On 2017-10-15 22:14, Yan Vugenfirer wrote: >> He Geoff, >> The official virtio-win drivers upstream repository is here: >> https://github.com/virtio-win/kvm-guest-drivers-windows >> 1. There is no ivshmem Windows Driver for now as far as I know >> 2. We are signing the drivers for community usage >> https://fedoraproject.org/wiki/Windows_Virtio_Drivers from the same >> repository. >> The process will be: submit the code for review with pull request >> (better use existing virtio library for virtio communication between >> the guest and the host), pass internal tests and at the least being >> able to pass MS HCK\HLK tests, later on the driver will be pulled into >> official build and release with rest of the drivers for community >> usage. >> 3. We are happy to cooperate on adding new functionality to current >> package of virtio drivers for Windows >> 4. As already mentioned: >> https://github.com/virtio-win/kvm-guest-drivers-windows >> Thanks a lot! >> If you have more questions, please don’t hesitate to talk to me, Ladi >> or anyone else from Red Hat involved with virtio-win development. >> Best regards, >> Yan. >>> On 15 Oct 2017, at 12:32, geoff--- via Qemu-devel <qemu-devel@nongnu.org> >>> wrote: >>> Hi All, >>> I am writing some code that needs to share a block of ram between a Windows >>> guest and Linux host. For this I am using the ivshmem device and I have >>> written a very primitive driver for windows that allows a single >>> application to request to memory map the pci bar (shared memory) into the >>> program's context using DeviceIoControl. >>> This is all working fine, but the next problem is I need the driver to be >>> signed. In it's current state I would not even suggest it be signed as it >>> was just hacked together to test my concept, but now I know it's viable I >>> would be willing to invest whatever time is required to write a driver that >>> would be acceptable for signing. >>> The ideal driver would be general purpose and could be leveraged for any >>> user mode application use, not just my specific case. It would need to >>> implement the IRQ/even features of ivshmem and possibly even some kind of >>> security to prevent unauthorized use by rogue applications (shared secret >>> configured on the chardev?). >>> I have several qustions: >>> 1) Has someone done this? I can't find any reference to a windows driver >>> for this device anywhere. >>> 2) If I was to pursue writing this driver, how would be the best way to go >>> about it so as to ensure that it is in a state that it could be signed with >>> the RedHat vendor key? >>> 3) What is the likelihood of having such a driver signed? >>> 4) Is there a preferred git host for such a driver? >>> Kind Regards >>> -Geoff >