All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, Liang Z" <liang.z.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Keir Fraser <keir@xen.org>,
	"Chang, JianzhongX" <jianzhongx.chang@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 05/10] x86/MSI: track host and guest masking separately
Date: Fri, 1 Apr 2016 09:21:40 +0000	[thread overview]
Message-ID: <F2CBF3009FA73547804AE4C663CAB28E04160F26@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <56FE51CE02000078000E1EEC@prv-mh.provo.novell.com>

> >>> On 01.04.16 at 09:40, <liang.z.li@intel.com> wrote:
> > A couple of weeks ago, Jianzhong reported an issue, the SRIOV NICs
> > (Intel 82599, 82571 ) can't work correctly in Windows guest.
> > By debugging, we found your this patch, the commit ID
> > ad28e42bd1d28d746988ed71654e8aa670629753,  caused the regression.
> 
> That was obvious.
> 
> > Could you help to take a look which part of your change lead to the
> > regression?
> > The SRIOV NICs works well in Linux guest.
> 
> As you may have seen, I've already found and fixed one aspect.
> I'm in the process of fixing another because, no, SRIOV NICs do not work well
> in Linux guests, at least not in recent ones (first noticed in 4.4, but last time I
> had tried before was with 4.0 I think) with CONFIG_XEN off.
> 
> Beyond that I guess I could use some help in at least diagnosing the issue, e.g.
> by logging the actions done by Xen, so we can understand why
> guest_mask_msi_irq() doesn't get called to unmask the MSI-X vector(s). I've
> found the reason why this isn't happening on Linux, and I am testing a
> possible fix. However, from the logs I've seen so far for Windows (with older

Glad to hear that you are working on this. Thanks!

> Xen, and with the above mentioned fix
> backported) it is already clear that this change won't help there (unless of
> course the issue you see is Windows version dependent).

> And just to be clear - the change previously proposed by Jianzhong is still not
> going to be an option: We need to understand and address the root cause of
> the issue, not paper over it by guessing when to unmask interrupts.
> 

Totally agree.

Liang
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-04-01  9:21 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-05 11:09 [PATCH v3 00/10] x86/MSI-X: XSA-120, 128..131 follow-up Jan Beulich
2015-06-05 11:20 ` [PATCH v3 01/10] x86/MSI-X: be more careful during teardown Jan Beulich
2015-06-05 11:20 ` [PATCH v3 02/10] x86/MSI-X: access MSI-X table only after having enabled MSI-X Jan Beulich
2015-06-05 13:01   ` Andrew Cooper
2015-06-05 11:21 ` [PATCH v3 03/10] x86/MSI-X: reduce fiddling with control register during restore Jan Beulich
2015-06-05 11:21 ` [PATCH v3 04/10] x86/MSI-X: cleanup Jan Beulich
2015-06-05 11:22 ` [PATCH v3 05/10] x86/MSI: track host and guest masking separately Jan Beulich
2015-06-05 13:05   ` Andrew Cooper
2016-04-01  7:40   ` Li, Liang Z
2016-04-01  8:47     ` Jan Beulich
2016-04-01  9:21       ` Li, Liang Z [this message]
2016-04-01  9:33         ` Jan Beulich
2015-06-05 11:23 ` [PATCH v3 06/10] x86/vMSI-X: cleanup Jan Beulich
2015-06-05 13:07   ` Andrew Cooper
2015-06-05 11:24 ` [PATCH v3 07/10] x86/vMSI-X: support qword MMIO access Jan Beulich
2015-06-05 15:34   ` Andrew Cooper
2015-06-05 11:25 ` [PATCH v3 08/10] x86/MSI-X: use qword MMIO access for address writes Jan Beulich
2015-06-05 15:37   ` Andrew Cooper
2015-06-05 11:26 ` [PATCH v3 09/10] VT-d: use qword MMIO access for MSI " Jan Beulich
2015-06-05 15:39   ` Andrew Cooper
2015-06-05 15:46     ` Jan Beulich
2015-06-11  7:45   ` Tian, Kevin
2015-06-05 11:28 ` [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control Jan Beulich
2015-06-05 15:57   ` Andrew Cooper
2015-06-05 16:17     ` Jan Beulich
2015-06-11  8:35   ` Jan Beulich
2015-06-11  9:51     ` Andrew Cooper
2015-06-19 13:00       ` Jan Beulich
2015-06-19 13:05         ` Konrad Rzeszutek Wilk
2015-06-19 14:52           ` Jan Beulich
2015-06-19 14:07         ` Roger Pau Monné
2015-06-19 14:58           ` Jan Beulich
2015-06-22 17:02             ` Roger Pau Monné
2015-06-23  7:20               ` Jan Beulich
2015-06-23  7:29                 ` Roger Pau Monné
2015-06-23  8:13                   ` Jan Beulich
2015-06-22 11:25           ` Jan Beulich
2015-06-12 13:21     ` Konrad Rzeszutek Wilk
2015-06-12 13:51       ` Jan Beulich
2015-06-12 14:17         ` Konrad Rzeszutek Wilk

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=F2CBF3009FA73547804AE4C663CAB28E04160F26@shsmsx102.ccr.corp.intel.com \
    --to=liang.z.li@intel.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jianzhongx.chang@intel.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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.