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
<address@hidden> 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