qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] ivshmem Windows Driver


From: Yan Vugenfirer
Subject: Re: [Qemu-devel] ivshmem Windows Driver
Date: Sun, 15 Oct 2017 14:14:25 +0300

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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]