All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [PATCH] vfio-pci: Quirk RTL8168 NIC
Date: Mon, 12 May 2014 14:28:33 -0600	[thread overview]
Message-ID: <1399926513.6734.123.camel@bling.home> (raw)
In-Reply-To: <20140512200237.GA2418@electric-eye.fr.zoreil.com>

On Mon, 2014-05-12 at 22:02 +0200, Francois Romieu wrote:
> Alex Williamson <alex.williamson@redhat.com> :
> [...]
> > device MSI will be blocked.  The Linux driver doesn't make use of this
> > window, so apparently it's not required to make use of MSI-X.  This
> 
> It does not really use MSI-X (no RSS).

Oh right, I looked for code references to the register but didn't notice
that Linux configures it for MSI, not MSI-X.  In my brief testing I only
saw that Windows generates interrupts on the first vector, so perhaps
not much lost without the extra vectors.  I guess it's this patch that
proves that MSI-X can be configured without this backdoor then.  Do you
have any insight into why this exists?

> > quirk makes the device work with the Windows driver that does use this
> > window for MSI-X, but I certainly cannot recommend this device for
> > assignment (the Windows 7 driver also constantly pokes PCI config
> > space).
> 
> Do you have some offsets for those ?

I believe it was 0x80, which is 0x10 off from the PCIe capability, so
the link control register.  I don't seem to have a log, but I'll
regenerate one tonight to get the exact sequence (the interface is in
use right now).

> > diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
> > index 9cf5b84..c3d2f7a 100644
> > --- a/hw/misc/vfio.c
> > +++ b/hw/misc/vfio.c
> [...]
> > + * "address latched" indicator.  Bits 12:15 is a mask field, which we're
> > + * going to ignore because we don't really know what it means and the MSI-X
> > + * area always seems to be accessed with a full mask.
> 
> s/seems to/should always/
> 
> Double word accesses requires the full mask. The MSIX area should be accessed
> through double words.

Good to know, I'll amend the comment.  Thanks!

Alex


WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] vfio-pci: Quirk RTL8168 NIC
Date: Mon, 12 May 2014 14:28:33 -0600	[thread overview]
Message-ID: <1399926513.6734.123.camel@bling.home> (raw)
In-Reply-To: <20140512200237.GA2418@electric-eye.fr.zoreil.com>

On Mon, 2014-05-12 at 22:02 +0200, Francois Romieu wrote:
> Alex Williamson <alex.williamson@redhat.com> :
> [...]
> > device MSI will be blocked.  The Linux driver doesn't make use of this
> > window, so apparently it's not required to make use of MSI-X.  This
> 
> It does not really use MSI-X (no RSS).

Oh right, I looked for code references to the register but didn't notice
that Linux configures it for MSI, not MSI-X.  In my brief testing I only
saw that Windows generates interrupts on the first vector, so perhaps
not much lost without the extra vectors.  I guess it's this patch that
proves that MSI-X can be configured without this backdoor then.  Do you
have any insight into why this exists?

> > quirk makes the device work with the Windows driver that does use this
> > window for MSI-X, but I certainly cannot recommend this device for
> > assignment (the Windows 7 driver also constantly pokes PCI config
> > space).
> 
> Do you have some offsets for those ?

I believe it was 0x80, which is 0x10 off from the PCIe capability, so
the link control register.  I don't seem to have a log, but I'll
regenerate one tonight to get the exact sequence (the interface is in
use right now).

> > diff --git a/hw/misc/vfio.c b/hw/misc/vfio.c
> > index 9cf5b84..c3d2f7a 100644
> > --- a/hw/misc/vfio.c
> > +++ b/hw/misc/vfio.c
> [...]
> > + * "address latched" indicator.  Bits 12:15 is a mask field, which we're
> > + * going to ignore because we don't really know what it means and the MSI-X
> > + * area always seems to be accessed with a full mask.
> 
> s/seems to/should always/
> 
> Double word accesses requires the full mask. The MSIX area should be accessed
> through double words.

Good to know, I'll amend the comment.  Thanks!

Alex

  reply	other threads:[~2014-05-12 20:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-10 23:03 [PATCH] vfio-pci: Quirk RTL8168 NIC Alex Williamson
2014-05-10 23:03 ` [Qemu-devel] " Alex Williamson
2014-05-12 20:02 ` Francois Romieu
2014-05-12 20:02   ` [Qemu-devel] " Francois Romieu
2014-05-12 20:28   ` Alex Williamson [this message]
2014-05-12 20:28     ` Alex Williamson
2014-05-13  3:06     ` Alex Williamson
2014-05-13 22:22       ` Francois Romieu

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=1399926513.6734.123.camel@bling.home \
    --to=alex.williamson@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=romieu@fr.zoreil.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.