| Message ID | 5718FD7802000078000E4613@prv-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2016-04-21 22:19 GMT+08:00 Jan Beulich <JBeulich@suse.com>: > >>> On 30.03.16 at 09:28, <changjzh@gmail.com> wrote: > > 2016-03-29 18:39 GMT+08:00 Jan Beulich <JBeulich@suse.com>: > >> --- > >> I assume this also addresses the issue which > >> > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03189.html > >> attempted to deal with in a not really acceptable way. > > > > I hope this issue is resolved, but it still exists. > > Mind giving the small below patch a try? > > Jan > > --- unstable.orig/xen/arch/x86/msi.c > +++ unstable/xen/arch/x86/msi.c > @@ -430,8 +430,13 @@ static bool_t msi_set_mask_bit(struct ir > { > writel(flag, entry->mask_base + > PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); > readl(entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); > + > if ( likely(control & PCI_MSIX_FLAGS_ENABLE) ) > break; > + > + entry->msi_attrib.host_masked = host; > + entry->msi_attrib.guest_masked = guest; > + > flag = 1; > } > else if ( flag && !(control & PCI_MSIX_FLAGS_MASKALL) ) > > > The issue still exist. But, the host_masked is changed. guest_masked can be changed by guest_mask_msi_irq() function. The function is not called as previous e-mail analysis. No patch xen log message: (XEN) MSI-X 114 vec=73 lowest edge assert log lowest dest=00000555 mask=1/HG/1 (XEN) MSI-X 115 vec=7b lowest edge assert log lowest dest=00000555 mask=1/HG/1 (XEN) MSI-X 116 vec=83 lowest edge assert log lowest dest=00000555 mask=1/HG/1 Patched-xen log message : (XEN) MSI-X 114 vec=76 lowest edge assert log lowest dest=00000555 mask=1/ G/1 (XEN) MSI-X 115 vec=7e lowest edge assert log lowest dest=00000555 mask=1/ G/1 (XEN) MSI-X 116 vec=86 lowest edge assert log lowest dest=00000555 mask=1/ G/1
>>> On 22.04.16 at 04:02, <changjzh@gmail.com> wrote: > 2016-04-21 22:19 GMT+08:00 Jan Beulich <JBeulich@suse.com>: > >> >>> On 30.03.16 at 09:28, <changjzh@gmail.com> wrote: >> > 2016-03-29 18:39 GMT+08:00 Jan Beulich <JBeulich@suse.com>: >> >> --- >> >> I assume this also addresses the issue which >> >> >> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03189.html >> >> attempted to deal with in a not really acceptable way. >> > >> > I hope this issue is resolved, but it still exists. >> >> Mind giving the small below patch a try? >> >> Jan >> >> --- unstable.orig/xen/arch/x86/msi.c >> +++ unstable/xen/arch/x86/msi.c >> @@ -430,8 +430,13 @@ static bool_t msi_set_mask_bit(struct ir >> { >> writel(flag, entry->mask_base + >> PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); >> readl(entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); >> + >> if ( likely(control & PCI_MSIX_FLAGS_ENABLE) ) >> break; >> + >> + entry->msi_attrib.host_masked = host; >> + entry->msi_attrib.guest_masked = guest; >> + >> flag = 1; >> } >> else if ( flag && !(control & PCI_MSIX_FLAGS_MASKALL) ) >> >> >> The issue still exist. But, the host_masked is changed. At least something. > guest_masked can be changed by guest_mask_msi_irq() function. > The function is not called as previous e-mail analysis. I have to admit that I had quite a bit of trouble understanding that previous patch of yours. The function not being called of course needs to be understood, which requires a trace of the writes of the guest to the vector control field(s), including the ones before the MSI-X region gets registered. Just to double check - was this latest try with the other patch also in place, or just the small one I had sent yesterday? I do have a debugging patch around for the necessary logging to get added, but that's against quite a bit older a hypervisor version, so likely would serve only as a reference. Let me know if you would still like me to hand that to you. Jan > No patch xen log message: > (XEN) MSI-X 114 vec=73 lowest edge assert log lowest dest=00000555 > mask=1/HG/1 > (XEN) MSI-X 115 vec=7b lowest edge assert log lowest dest=00000555 > mask=1/HG/1 > (XEN) MSI-X 116 vec=83 lowest edge assert log lowest dest=00000555 > mask=1/HG/1 > > Patched-xen log message : > (XEN) MSI-X 114 vec=76 lowest edge assert log lowest dest=00000555 > mask=1/ G/1 > (XEN) MSI-X 115 vec=7e lowest edge assert log lowest dest=00000555 > mask=1/ G/1 > (XEN) MSI-X 116 vec=86 lowest edge assert log lowest dest=00000555 > mask=1/ G/1 > > -- > Jianzhong,Chang
> >> >>> On 30.03.16 at 09:28, <changjzh@gmail.com> wrote: > >> > 2016-03-29 18:39 GMT+08:00 Jan Beulich <JBeulich@suse.com>: > >> >> --- > >> >> I assume this also addresses the issue which > >> >> > >> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03189. > >> html > >> >> attempted to deal with in a not really acceptable way. > >> > > >> > I hope this issue is resolved, but it still exists. > >> > >> Mind giving the small below patch a try? > >> > >> Jan > >> > >> --- unstable.orig/xen/arch/x86/msi.c > >> +++ unstable/xen/arch/x86/msi.c > >> @@ -430,8 +430,13 @@ static bool_t msi_set_mask_bit(struct ir > >> { > >> writel(flag, entry->mask_base + > >> PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); > >> readl(entry->mask_base + > >> PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); > >> + > >> if ( likely(control & PCI_MSIX_FLAGS_ENABLE) ) > >> break; > >> + > >> + entry->msi_attrib.host_masked = host; > >> + entry->msi_attrib.guest_masked = guest; > >> + > >> flag = 1; > >> } > >> else if ( flag && !(control & PCI_MSIX_FLAGS_MASKALL) ) > >> > >> > >> The issue still exist. But, the host_masked is changed. > > At least something. > > > guest_masked can be changed by guest_mask_msi_irq() function. > > The function is not called as previous e-mail analysis. > > I have to admit that I had quite a bit of trouble understanding that previous > patch of yours. The function not being called of course needs to be > understood, which requires a trace of the writes of the guest to the vector > control field(s), including the ones before the MSI-X region gets registered. > Just to double check - was this latest try with the other patch also in place, or > just the small one I had sent yesterday? > With other patches also in place, still not work. Jianzhong has been left and Quan will take over the task. Liang > I do have a debugging patch around for the necessary logging to get added, > but that's against quite a bit older a hypervisor version, so likely would serve > only as a reference. Let me know if you would still like me to hand that to you. > > Jan > > > No patch xen log message: > > (XEN) MSI-X 114 vec=73 lowest edge assert log lowest dest=00000555 > > mask=1/HG/1 > > (XEN) MSI-X 115 vec=7b lowest edge assert log lowest dest=00000555 > > mask=1/HG/1 > > (XEN) MSI-X 116 vec=83 lowest edge assert log lowest dest=00000555 > > mask=1/HG/1 > > > > Patched-xen log message : > > (XEN) MSI-X 114 vec=76 lowest edge assert log lowest dest=00000555 > > mask=1/ G/1 > > (XEN) MSI-X 115 vec=7e lowest edge assert log lowest dest=00000555 > > mask=1/ G/1 > > (XEN) MSI-X 116 vec=86 lowest edge assert log lowest dest=00000555 > > mask=1/ G/1 > > > > -- > > Jianzhong,Chang > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On April 25, 2016 4:41pm, Li, Liang Z <liang.z.li@intel.com> wrote: > > >> >>> On 30.03.16 at 09:28, <changjzh@gmail.com> wrote: > > >> > 2016-03-29 18:39 GMT+08:00 Jan Beulich <JBeulich@suse.com>: > > >> >> --- > > >> >> I assume this also addresses the issue which > > >> >> > > >> http://lists.xenproject.org/archives/html/xen-devel/2016- > 01/msg03189. > > >> html > > >> >> attempted to deal with in a not really acceptable way. > > >> > > > >> > I hope this issue is resolved, but it still exists. > > >> > > >> Mind giving the small below patch a try? > > >> > > >> Jan > > >> > > >> --- unstable.orig/xen/arch/x86/msi.c > > >> +++ unstable/xen/arch/x86/msi.c > > >> @@ -430,8 +430,13 @@ static bool_t msi_set_mask_bit(struct ir > > >> { > > >> writel(flag, entry->mask_base + > > >> PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); > > >> readl(entry->mask_base + > > >> PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); > > >> + > > >> if ( likely(control & PCI_MSIX_FLAGS_ENABLE) ) > > >> break; > > >> + > > >> + entry->msi_attrib.host_masked = host; > > >> + entry->msi_attrib.guest_masked = guest; > > >> + > > >> flag = 1; > > >> } > > >> else if ( flag && !(control & PCI_MSIX_FLAGS_MASKALL) ) > > >> > > >> > > >> The issue still exist. But, the host_masked is changed. > > > > At least something. > > > > > guest_masked can be changed by guest_mask_msi_irq() function. > > > The function is not called as previous e-mail analysis. > > > > I have to admit that I had quite a bit of trouble understanding that > > previous patch of yours. The function not being called of course needs > > to be understood, which requires a trace of the writes of the guest to > > the vector control field(s), including the ones before the MSI-X region gets > registered. > > Just to double check - was this latest try with the other patch also > > in place, or just the small one I had sent yesterday? > > > > With other patches also in place, still not work. > Jianzhong has been left and Quan will take over the task. > Yes, I am just getting warmed up..:) Quan > Liang > > > I do have a debugging patch around for the necessary logging to get > > added, but that's against quite a bit older a hypervisor version, so > > likely would serve only as a reference. Let me know if you would still like me > to hand that to you. > > > > Jan > > > > > No patch xen log message: > > > (XEN) MSI-X 114 vec=73 lowest edge assert log lowest dest=00000555 > > > mask=1/HG/1 > > > (XEN) MSI-X 115 vec=7b lowest edge assert log lowest dest=00000555 > > > mask=1/HG/1 > > > (XEN) MSI-X 116 vec=83 lowest edge assert log lowest dest=00000555 > > > mask=1/HG/1 > > > > > > Patched-xen log message : > > > (XEN) MSI-X 114 vec=76 lowest edge assert log lowest dest=00000555 > > > mask=1/ G/1 > > > (XEN) MSI-X 115 vec=7e lowest edge assert log lowest dest=00000555 > > > mask=1/ G/1 > > > (XEN) MSI-X 116 vec=86 lowest edge assert log lowest dest=00000555 > > > mask=1/ G/1 > > > > > > -- > > > Jianzhong,Chang
>>> On 25.04.16 at 10:40, <liang.z.li@intel.com> wrote: > With other patches also in place, still not work. > Jianzhong has been left and Quan will take over the task. May I ask for another try, with current tip of staging plus http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg03661.html ? Thanks, Jan
On April 28, 2016 11:13 PM, Jan Beulich <JBeulich@suse.com> wrote: > >>> On 25.04.16 at 10:40, <liang.z.li@intel.com> wrote: > > With other patches also in place, still not work. > > Jianzhong has been left and Quan will take over the task. > > May I ask for another try, with current tip of staging plus > http://lists.xenproject.org/archives/html/xen-devel/2016- > 04/msg03661.html > ? Sure, I will try it on tomorrow afternoon or next Tuesday. Quan
On April 29, 2016 12:11 AM, <quan.xu@intel.com> wrote: > On April 28, 2016 11:13 PM, Jan Beulich <JBeulich@suse.com> wrote: > > >>> On 25.04.16 at 10:40, <liang.z.li@intel.com> wrote: > > > With other patches also in place, still not work. > > > Jianzhong has been left and Quan will take over the task. > > > > May I ask for another try, with current tip of staging plus > > http://lists.xenproject.org/archives/html/xen-devel/2016- > > 04/msg03661.html > > ? > > > Sure, I will try it on tomorrow afternoon or next Tuesday. Jan, Sorry, this is still working in progress. The original env is broken. I am rebuilding a new env, with some problems of Windows image. I checked the staging branch, and I found your patches are in staging branch now, so I am just going to test staging branch. Right? Quan
>>> On 03.05.16 at 14:50, <quan.xu@intel.com> wrote: > On April 29, 2016 12:11 AM, <quan.xu@intel.com> wrote: >> On April 28, 2016 11:13 PM, Jan Beulich <JBeulich@suse.com> wrote: >> > >>> On 25.04.16 at 10:40, <liang.z.li@intel.com> wrote: >> > > With other patches also in place, still not work. >> > > Jianzhong has been left and Quan will take over the task. >> > >> > May I ask for another try, with current tip of staging plus >> > http://lists.xenproject.org/archives/html/xen-devel/2016- >> > 04/msg03661.html >> > ? >> >> >> Sure, I will try it on tomorrow afternoon or next Tuesday. > > Jan, > Sorry, this is still working in progress. > The original env is broken. I am rebuilding a new env, with some problems > of Windows image. > I checked the staging branch, and I found your patches are in staging branch > now, > so I am just going to test staging branch. Right? Yes.
On May 03, 2016 9:39 PM, Jan Beulich <JBeulich@suse.com> wrote: > >>> On 03.05.16 at 14:50, <quan.xu@intel.com> wrote: > > On April 29, 2016 12:11 AM, <quan.xu@intel.com> wrote: > >> On April 28, 2016 11:13 PM, Jan Beulich <JBeulich@suse.com> wrote: > >> > >>> On 25.04.16 at 10:40, <liang.z.li@intel.com> wrote: > >> > > With other patches also in place, still not work. > >> > > Jianzhong has been left and Quan will take over the task. > >> > > >> > May I ask for another try, with current tip of staging plus > >> > http://lists.xenproject.org/archives/html/xen-devel/2016- > >> > 04/msg03661.html > >> > ? > >> > >> > >> Sure, I will try it on tomorrow afternoon or next Tuesday. > > > > Jan, > > Sorry, this is still working in progress. > > The original env is broken. I am rebuilding a new env, with some > > problems of Windows image. > > I checked the staging branch, and I found your patches are in staging > > branch now, so I am just going to test staging branch. Right? > > Yes. Jan, The VF is still _not_ working for Windows_Server2008, but the PF does. My nic is 'Intel Corporation I350 Gigabit Network Connection', and the last commit is 'c2994f86'. I also tested the RHEL6 VM, the same result as Windows_Server2008. I'll also go into this issue. Any update, let me help you test it. Quan
On April 28, 2016 11:13 PM, Jan Beulich <JBeulich@suse.com> wrote: > >>> On 25.04.16 at 10:40, <liang.z.li@intel.com> wrote: > > With other patches also in place, still not work. > > Jianzhong has been left and Quan will take over the task. > > May I ask for another try, with current tip of staging plus > http://lists.xenproject.org/archives/html/xen-devel/2016- > 04/msg03661.html > ? Jan, The same issue for rhel 6.4VM, which cannot initialize VF driver too.. the below is log of rhel 6.4 VM: .. igbvf: 0000:00.04.0: Invalid MAC Address: 00:00:00:00:00:00 igbvf: probe of 0000:00.04.0 failed with error -5 .. But when I tried to initialize VF MAC in Dom0 with e.g.: $ip link set eth0 vf 0 mac 00:1E:67:65:93:01 Then to create rhel 6.4 VM again, the VF is working for rhel 6.4 VM. I will ask QA team to help me verify it on win2k8 guest (I'm not sure whether the win2k8 network driver is working or not). Quan
>>> On 19.05.16 at 10:30, <quan.xu@intel.com> wrote: > On April 28, 2016 11:13 PM, Jan Beulich <JBeulich@suse.com> wrote: >> >>> On 25.04.16 at 10:40, <liang.z.li@intel.com> wrote: >> > With other patches also in place, still not work. >> > Jianzhong has been left and Quan will take over the task. >> >> May I ask for another try, with current tip of staging plus >> http://lists.xenproject.org/archives/html/xen-devel/2016- >> 04/msg03661.html >> ? > > The same issue for rhel 6.4VM, which cannot initialize VF driver too.. the > below is log of rhel 6.4 VM: > .. > igbvf: 0000:00.04.0: Invalid MAC Address: 00:00:00:00:00:00 > igbvf: probe of 0000:00.04.0 failed with error -5 > .. > > But when I tried to initialize VF MAC in Dom0 with e.g.: > $ip link set eth0 vf 0 mac 00:1E:67:65:93:01 Makes things even more strange, as things work fine for me with SLE11 and SLE12 guests. But I have to admit that the "Invalid MAC Address" looks quite unrelated, i.e. is this perhaps some completely different problem you have? Again, considering that you have a repro (while I don't), the easiest would be to simply log all MSI-X related actions (there shouldn't be too many), to see where things go wrong. Such a log alone would maybe already allow me to do further investigation. Jan
On May 19, 2016 5:15 PM, Jan Beulich <JBeulich@suse.com> wrote: > >>> On 19.05.16 at 10:30, <quan.xu@intel.com> wrote: > > On April 28, 2016 11:13 PM, Jan Beulich <JBeulich@suse.com> wrote: > >> >>> On 25.04.16 at 10:40, <liang.z.li@intel.com> wrote: > >> > With other patches also in place, still not work. > >> > Jianzhong has been left and Quan will take over the task. > >> > >> May I ask for another try, with current tip of staging plus > >> http://lists.xenproject.org/archives/html/xen-devel/2016- > >> 04/msg03661.html > >> ? > > > > The same issue for rhel 6.4VM, which cannot initialize VF driver > > too.. the below is log of rhel 6.4 VM: > > .. > > igbvf: 0000:00.04.0: Invalid MAC Address: 00:00:00:00:00:00 > > igbvf: probe of 0000:00.04.0 failed with error -5 > > .. > > > > But when I tried to initialize VF MAC in Dom0 with e.g.: > > $ip link set eth0 vf 0 mac 00:1E:67:65:93:01 > > Makes things even more strange, as things work fine for me with > SLE11 and SLE12 guests. But I have to admit that the "Invalid MAC Address" > looks quite unrelated, i.e. is this perhaps some completely different problem > you have? I tried to run SLE12 guest. Things are really working fine for me too.. But not for rhel 6.4 guest.. So far, I think the bug is not from xen hypervisor, just from vf driver. Look at this bug, even from KVM --- igb VF can't work in KVM guest, https://bugzilla.kernel.org/show_bug.cgi?id=55421 > > Again, considering that you have a repro (while I don't), the easiest would be > to simply log all MSI-X related actions (there shouldn't be too many), to see > where things go wrong. Such a log alone would maybe already allow me to do > further investigation. > I need more time to read this part, but sure I will follow it. Quan
--- unstable.orig/xen/arch/x86/msi.c +++ unstable/xen/arch/x86/msi.c @@ -430,8 +430,13 @@ static bool_t msi_set_mask_bit(struct ir { writel(flag, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); readl(entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET); + if ( likely(control & PCI_MSIX_FLAGS_ENABLE) ) break; + + entry->msi_attrib.host_masked = host; + entry->msi_attrib.guest_masked = guest; + flag = 1; } else if ( flag && !(control & PCI_MSIX_FLAGS_MASKALL) )