>>> On 02.06.16 at 13:03, wrote: > On Thu, Jun 02, 2016 at 04:38:47AM -0600, Jan Beulich wrote: >> >>> On 02.06.16 at 12:22, wrote: >> > On Thu, Jun 02, 2016 at 07:31:06AM +0000, Xu, Quan wrote: >> >> On May 27, 2016 10:06 PM, Jan Beulich wrote: >> >> > >>> On 27.05.16 at 15:34, wrote: >> >> > > On Fri, May 27, 2016 at 06:16:30AM -0600, Jan Beulich wrote: >> >> > >> >>> On 27.05.16 at 12:39, 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. Jan > And then maybe Quan and Pengtao can give an estimation on how long it > takes to gather all necessary information and move on to next stage. > > Wei. > >> Jan >>