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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan

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