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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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

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