[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [win-pv-devel] Windows 10 domU hang on boot after pv drivers install if dom0 have old kernel (or specific 3.2 problem)



Il 09/11/2015 15:42, Paul Durrant ha scritto:
-----Original Message-----
[snip]
I know since long time ago that winpv require xen>=4.5.0 and upstream
qemu>=1.6.1
Probably also backports of these xen patches are needed if xen<4.6
(based on critical problems had long time ago):
- x86/hvm: add per-vcpu evtchn upcalls
There was a bug in XENBUS which would cause a boot-time hang if you
were not running a Xen with this patch, but that was fixed by:
commit 021d1f91ff9c1c10fa59e6d4200628b9d0d37eab
Author: Paul Durrant <paul.durrant@xxxxxxxxxx>
Date:   Thu Jul 2 10:23:26 2015 +0100

      Fix fall-back to two-level EVTCHN ABI

      When the EVTCHN code attempts to acquire the FIFO ABI it may fail to
do
      so because the version of Xen may not support it. In this case the code
      was issuing an EventChannelReset() which has the unfortunate side
effect of
      killing any toolstack-created channels, such as the xenstored channel.

      This patch moves the existent EvtchnFifoReset function into the base
      evtchn source module (since it's not ABI specific) and uses that function
      as the only mechanism of issuing an EventChannelReset() since it
contains
      code to preserve event channel bindings. (Prior to the move it only
      preserved the xenstore channel but this patch adds code to preserve
the
      console event channel too, if it exists).

      Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>

...which is in the staging-8.1 branch and hence will be in the 8.1 release.

- x86/hvm: extend HVM cpuid leaf with vcpu id

This is not relied upon so you should be ok without it.

    Paul
Thanks for your reply.
Based on your reply with recent winpv builds don't require backport of
these xen patches but only require xen>=4.5.0 and upstream qemu>=1.6.1.

About the problem reported in this mail that seems related to the kernel
(the only different thing comparing with test server), what can you tell
me about?

The other thing that comes to mind is this fix in xen-netback:

commit 279f438e36c0a70b23b86d2090aeec50155034a9
Author: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
Date:   Tue Sep 17 17:46:08 2013 +0100

     xen-netback: Don't destroy the netdev until the vif is shut down

     Without this patch, if a frontend cycles through states Closing
     and Closed (which Windows frontends need to do) then the netdev
     will be destroyed and requires re-invocation of hotplug scripts
     to restore state before the frontend can move to Connected. Thus
     when udev is not in use the backend gets stuck in InitWait.

     With this patch, the netdev is left alone whilst the backend is
     still online and is only de-registered and freed just prior to
     destroying the vif (which is also nicely symmetrical with the
     netdev allocation and registration being done during probe) so
     no re-invocation of hotplug scripts is required.

     Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
     Cc: David Vrabel <david.vrabel@xxxxxxxxxx>
     Cc: Wei Liu <wei.liu2@xxxxxxxxxx>
     Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
     Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
     Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>

As you can see, it's pretty old, but wheezy is older.

   Paul

Big thanks for the reply.
This patch is missed in 3.2 upstream and also in debian patches.
I'll try rebuild with it ASAP for see if it solve the problem and backport request is needed (as 3.2 is an LTS)

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.