Re: [Qemu-devel] ivshmem Windows Driver

[geoff@hostfission.com]

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.

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