qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: geoff@hostfission.com
To: Ladi Prosek <lprosek@redhat.com>
Cc: Yan Vugenfirer <yvugenfi@redhat.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] ivshmem Windows Driver
Date: Wed, 18 Oct 2017 16:50:21 +1100	[thread overview]
Message-ID: <0f911b72c94a0d0f1bedf1c6385b045e@hostfission.com> (raw)
In-Reply-To: <CABdb734e-Fmfjk8auh-FzKnhmxjs0Bh9WpXWDmRBjYUWsZfe3A@mail.gmail.com>

On 2017-10-18 16:31, Ladi Prosek wrote:
> Hi Geoff,
> 
> On Mon, Oct 16, 2017 at 8:31 PM,  <geoff@hostfission.com> wrote:
>> Hi Yan & Ladi.
>> 
>> I have written an initial implementation that supports just the shared
>> memory
>> mapping at this time. I plan to add events also but before I go 
>> further I
>> would
>> like some feedback if possible on what I have implemented thus far.
>> 
>> Please see:
>> 
>> https://github.com/gnif/kvm-guest-drivers-windows/commit/8655cf12fbdd77b991f96d97bc20f967b5907c12
> 
> Thank you, looks good overall.
> 
> * Please don't use the 'vio' prefix for this driver. ivshmem is not a
> VirtIO device (i.e. not using the VirtIO protocol). Also the test
> program should live in a subdirectory, so maybe something like
> /ivshmem and /ivshmem/test.

Noted, I will remove the prefix throughout and move the test 
application.

> 
> * In VIOIVSHMEMEvtDevicePrepareHardware: I don't think that Windows
> guarantees that resources are enumerated in BAR order. In VirtIO
> drivers we read the PCI config space to identify the BAR index:
> https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/VirtIO/VirtIOPCICommon.c#L353

The windows 'toaster' sample relies on the resource order, but as a
belt and braces approach I will update the code to use the same
approach.

> 
> * IOCTL codes on Windows have a structure to them:
> https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/defining-i-o-control-codes

Thanks, I will fix this.

> 
> * In VIOIVSHMEMEvtIoDeviceControl: The "only one mapping at a time is
> allowed" test has a race. I think that simply making the IO queue
> WdfIoQueueDispatchSequential instead of WdfIoQueueDispatchParallel
> will fix it.

Good point, I will change this.

> 
> * According to MSDN, MmMapLockedPagesSpecifyCache(UserMode) should be
> wrapped in try/except. Also, what happens if the file handle is
> inherited by a child process? Can it unmap the mapping in parent's
> address space? What if the parent exits? A possible solution is
> discussed in this article:
> http://www.osronline.com/article.cfm?article=39

Noted re try/except. As for a child inheriting it, the owner is tracked
by the WDFFILEOBJECT, which the child I believe will inherit also, which
would mean that the child would gain the ability to issue IOCTLs to the
mapping.

> 
> Thanks!
> Ladi


No, thank you! I am grateful someone is willing to provide some feedback
on this.

I have been working on adding MSI interrupt support to the driver
also which is close to ready, just trying to figure out why the driver
fails to start with STATUS_DEVICE_POWER_FAILURE when I try to setup the
IRQs with WdfInterruptCreate.

Thanks again,
Geoff

  reply	other threads:[~2017-10-18  5:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-15  9:32 [Qemu-devel] ivshmem Windows Driver geoff
2017-10-15 11:14 ` Yan Vugenfirer
2017-10-15 12:21   ` geoff
2017-10-15 12:24     ` Yan Vugenfirer
2017-10-15 12:29       ` geoff
2017-10-16 18:31         ` geoff
2017-10-18  5:31           ` Ladi Prosek
2017-10-18  5:50             ` geoff [this message]
2017-10-18  6:50               ` Ladi Prosek
2017-10-18  6:56                 ` geoff
2017-10-18 12:34                   ` Ladi Prosek
2017-10-18 15:04                     ` geoff
2017-10-19  8:35                       ` Ladi Prosek
2017-10-19  8:44                         ` geoff
2017-10-19  9:01                           ` Ladi Prosek
2017-10-19  9:07                             ` geoff
2017-10-19  9:41                               ` geoff
2017-10-19  9:51                                 ` Ladi Prosek
2017-10-19 10:42                                   ` geoff
2017-10-16 15:20 ` Eric Blake
2017-10-16 16:05   ` geoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0f911b72c94a0d0f1bedf1c6385b045e@hostfission.com \
    --to=geoff@hostfission.com \
    --cc=lprosek@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yvugenfi@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).