Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

["Xu, Quan" <quan.xu@xxxxxxxxx>]

On June 02, 2016 9:30 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>> On 02.06.16 at 15:05, <quan.xu@xxxxxxxxx> wrote:
> > On June 02, 2016 8:09 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >> >>> On 02.06.16 at 13:03, <wei.liu2@xxxxxxxxxx> wrote:
> >> > On Thu, Jun 02, 2016 at 04:38:47AM -0600, Jan Beulich wrote:
> >> >> >>> On 02.06.16 at 12:22, <wei.liu2@xxxxxxxxxx> wrote:
> >> >> > On Thu, Jun 02, 2016 at 07:31:06AM +0000, Xu, Quan wrote:
> >> >> >> On May 27, 2016 10:06 PM, Jan Beulich <JBeulich@xxxxxxxx>
> wrote:
> >> >> >> > >>> On 27.05.16 at 15:34, <wei.liu2@xxxxxxxxxx> wrote:
> >> >> >> > > On Fri, May 27, 2016 at 06:16:30AM -0600, Jan Beulich wrote:
> >> >> >> > >> >>> On 27.05.16 at 12:39, <wei.liu2@xxxxxxxxxx> wrote:
> >> >> >> > >> > Is this a regression? Does it work on previous versions of 
> >> >> >> > >> > Xen?
> >> >> >> > >>
> >> >> >> > >> I think this is what was already reported by other Intel
> >> >> >> > >> people, see e.g. Quan's most recent reply:
> >> >> >> > >> http://lists.xenproject.org/archives/html/xen-devel/2016-
> >> 05/msg01896.
> >> >> >> > >> html It is not clear where the problem is, and not seeing
> >> >> >> > >> the issue myself makes it hard to analyze. In any event
> >> >> >> > >> this quite likely is a regression.
> >> >> >> > >>
> >> >> >> > >
> >> >> >> > > My reading of that email thread and all relevant links
> >> >> >> > > (including the KVM bug report) is that there is a
> >> >> >> > > regression vf driver,
> >> but not in Xen.
> >> >> >> >
> >> >> >> > Just from reading that I would tend to agree. But the report
> >> >> >> > here is about Win2K8.
> >> >> >>
> >> >> >> Do you know which commit is a regression one? I try to find out
> >> >> >> the
> >> >> > regression commit.  That may be helpful to find out the root cause.
> >> >> >>
> >> >> >> Btw, some feedback from QA team, rhel 6.4 VM  doesn't work, but
> >> >> >> rhel 7.2 VM
> >> > does.
> >> >> >
> >> >> > Isn't this at least an indication that the guest could be buggy here?
> >> >> > It could also be both the hypervsior and guest have bugs. But
> >> >> > we're just not sure at this point.
> >> >>
> >> >> Indeed, and (with the many fixes that went in already) I really
> >> >> suspect a combination of both, or some of the involved hypervisor
> >> >> changes having unmasked some guest issue. Regardless, I'm afraid
> >> >> this ought to be treated as a blocker for the release at least
> >> >> until we understand what the issue is. But otoh making it a
> >> >> blocker probably makes sense only if we can expect progress (which
> >> >> we haven't really made for quite long a time).
> >> >>
> >> >
> >> > This issue is on my list, but the information gathered so far isn't
> >> > convincing enough to make it a blocker.
> >> >
> >> > And yes, we need meaningful progress to make it a blocker. To make
> >> > it so, commitment from various parties is needed. Let's start with
> >> > setting out things to look at, who is going to investigate what,
> >> > and a possible timeline for each item.
> >> >
> >> > Jan, can you come up with a list of what sort of information you need?
> >>
> >> Well, I had hoped to avoid that. But now that you ask for it,
> >> providing an
> > initial
> >> debugging patch seems better than a description which may get
> >> misunderstood. Attached both a hypervisor and a qemu patch. Their
> >> plus debug key M and i output is what I'd like to start with.
> >>
> >
> >
> >      I will try these 2 patches.
> >
> > btw. I read the internal Bugzilla carefully. I found that vf is
> > working for
> > win2k8  at  '2014-12-01 14:32:09 EST', but the bug still exist on '
> > 2015-02-11
> > 15:54:05 EST '.
> > then, I grepped the commit logs, the below 4 MSI-X related commits are
> > may the root cause.
> 
> DYM "vif is not working", or is the use of "still" wrong (or at least 
> misleading in
> this context)? Because if the two dates frame the introduction of the bug,
> then it must be something completely different from what I so far have been
> thinking of.
> 
> > From 6fb3a07bc0ad656b5f76eb9fc961bcd1d3cace58 Mon Sep 17
> 00:00:00 2001
> > From: Jan Beulich <JBeulich@xxxxxxxx>
> > Date: Fri, 12 Dec 2014 10:24:13 +0000
> > Subject: [PATCH 13/44] domctl: fix IRQ permission granting/revocation
> >
> >
> > From 1965728cd5a1635859158f5800d844fc16774668 Mon Sep 17
> 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > Date: Mon, 12 Jan 2015 11:29:33 -0500
> > Subject: [PATCH 42/44] Revert "dpci: add 'masked' as a gate for
> > hvm_dirq_assist to process"
> >
> >
> > From 72f3c1e26e96686a41d2de1663e578538659f99a Mon Sep 17
> 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > Date: Mon, 12 Jan 2015 11:30:00 -0500
> > Subject: [PATCH 43/44] Revert "dpci: replace tasklet with softirq"
> >
> > rom a8ac2290ed95dbbc0dc1bdde86fc3a49fe784b28 Mon Sep 17
> 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > Date: Mon, 12 Jan 2015 11:30:05 -0500
> > Subject: [PATCH 44/44] Revert "dpci: move from an hvm_irq_dpci (and
> > struct
> >  domain) to an hvm_dirq_dpci model"
> 
> These all pre-date 4.5 - are you saying 4.5.0 (and note, I'm not asking about
> 4.5.1 or newer) is also broken? In particular the reverts above were done on
> the 4.5 release branch only, i.e.
> didn't ever occur on staging (and hence a staging tree from around that time
> should then be fine). Yet for understanding when the issue got introduced
> we'd need a range of staging commits.
> 
> All in all I'm afraid I'm now more confused than I was before.
> 


Sorry, this may be noise to you. Ignore them.


Quan

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