>>> On 15.02.17 at 15:55, <sergey.dya...@citrix.com> wrote: > On Wed, 2017-02-15 at 06:20 -0700, Jan Beulich wrote: >> > > > On 15.02.17 at 11:27, <sergey.dya...@citrix.com> wrote: >> > >> > This is what I'm getting during the original test case (32 VMs reboot): >> > >> > (XEN) [ 1407.789329] Watchdog timer detects that CPU12 is stuck! >> > (XEN) [ 1407.795726] ----[ Xen-4.6.1-xs-local x86_64 debug=n Not >> > tainted ]---- >> >> Hmm, this was with a non-debug build, so the ASSERT() in >> vmx_vmcs_reload() was a no-op, yet it would have been useful >> to know whether active_cpu was -1 when getting stuck here. >> Btw - there was no nested virt in the picture in your try, was >> there? > > No nested virt is involved in the test case. > > Is it worth giving your patch another try with removing ctxt_switch_same() > since we figured out that vmx_do_resume() will reload vmcs either way?
Yes, but that's the cosmetic part, whereras ... > And I will also update vmx_vmcs_reload() from your last email. ... this looks to be the actual bug fix. If you agree with my reasoning of removing the loop altogether, you may want to go with that version instead of adding the conditional. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
