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


  • To: Fabio Fantoni <fabio.fantoni@xxxxxxx>, "win-pv-devel@xxxxxxxxxxxxxxxxxxxx" <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Mon, 9 Nov 2015 16:21:59 +0000
  • Accept-language: en-GB, en-US
  • Delivery-date: Mon, 09 Nov 2015 16:22:07 +0000
  • List-id: Developer list for the Windows PV Drivers subproject <win-pv-devel.lists.xenproject.org>
  • Thread-index: AQHRGuwidG4ZcTbeE0qn+S2eGWVU1Z6Tq4QA///7YYCAABtyQP//+fWAgAAQy4CAABJosA==
  • Thread-topic: Windows 10 domU hang on boot after pv drivers install if dom0 have old kernel (or specific 3.2 problem)

> -----Original Message-----
> From: Fabio Fantoni [mailto:fabio.fantoni@xxxxxxx]
> Sent: 09 November 2015 16:15
> To: Paul Durrant; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: Windows 10 domU hang on boot after pv drivers install if dom0
> have old kernel (or specific 3.2 problem)
> 
> 
> 
> Il 09/11/2015 16:15, Fabio Fantoni ha scritto:
> > 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)
> 
> I tried to apply it to latest wheezy (3.2) but fails to apply and there
> are fails in drivers/net/xen-netback/interface.c hunk #2, #3 and #4 for
> parts missed or too different, same with latest upsteam (3.2.72).
> I not understand how to adapt it safely :(

Probably best just to use a newer kernel then.

  Paul

> 
> Thanks for any reply and sorry for my bad english.

_______________________________________________
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®.