Re: [win-pv-devel] Upcalls not enabled on a processor

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:win-pv-devel-
> bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Rafal Wojdyla
> Sent: 23 June 2015 00:19
> To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [win-pv-devel] Upcalls not enabled on a processor
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2015-06-23 00:59, RafaÅ WojdyÅa wrote:
> > On 2015-06-22 00:44, RafaÅ WojdyÅa wrote:
> >> Hi,
> >
> >> I've been testing the full pvdrivers package under Qubes and I see
> >> this problem happening sometimes. It seems that xenvif waits
> >> forever for backend state to change. Debug output seems to suggest
> >> that something else is the real cause of the problem and xenvif is
> >> just the first victim:
> >
> >> XENVIF|FrontendAcquireBackend: =====>
> >> XENVIF|FrontendWaitForBackendXenbusStateChange:
> >> /local/domain/2/backend/vif/14/0: ====> Unknown
> >> XENBUS|StoreProcessWatchEvent: 55b5
> >> (/local/domain/2/backend/vif/14/0/state)
> >> XENVIF|FrontendWaitForBackendXenbusStateChange:
> >> /local/domain/2/backend/vif/14/0: <==== (Closed)
> >> XENVIF|FrontendSetXenbusState: device/vif/0: ====> Initialising
> >> XENBUS|StoreProcessWatchEvent: 5599 (device/vif/0/state)
> >> XENBUS|StoreProcessWatchEvent: 55af (device/vif/0/state)
> >> XENVIF|FrontendSetXenbusState: device/vif/0: <==== Initialising
> >> XENVIF|FrontendWaitForBackendXenbusStateChange:
> >> /local/domain/2/backend/vif/14/0: ====> Closed
> >> XENBUS|StoreProcessWatchEvent: 55b6
> >> (/local/domain/2/backend/vif/14/0/state)
> >> XENVIF|FrontendWaitForBackendXenbusStateChange:
> >> /local/domain/2/backend/vif/14/0: <==== (InitWait)
> >> XENBUS|StoreProcessWatchEvent: 55b7
> >> (/local/domain/2/backend/vif/14/0/online) XENVIF|FrontendPrepare:
> >> <==== XENVIF|FrontendSetState: device/vif/0 in state 'PREPARED'
> >> XENVIF|FrontendConnect: ====> XENVIF|FrontendSetNumQueues: 2
> >> XENVIF|ReceiverConnect: ====> XENBUS|CacheCreate: ====>
> >> (device_vif_0_queue-0_receiver_gnttab) XENBUS|CacheCreate: <====
> >> XENBUS|EvtchnOpen: 9 XENBUS|EvtchnBind: fail1 (c00000bb)
> >> XENBUS|CacheCreate: ====> (device_vif_0_queue-1_receiver_gnttab)
> >> XENBUS|CacheCreate: <==== XENBUS|EvtchnOpen: 10
> XENBUS|EvtchnBind:
> >> fail1 (c00000bb) XENVIF|ReceiverConnect: <====
> >
> >> EvtchnBind fails with STATUS_NOT_SUPPORTED and that's caused by
> >> upcalls not being enabled on the processor. What can be the cause
> >> of this? EvtchnInterruptEnable is being called but apparently
> >> HvmSetEvtchnUpcallVector fails because I see no debug output that
> >> should be present if it succeeds. I guess I should check the
> >> hypervisor logs for any clues...
> >
> > I've done some more testing and I'm even more confused. The hypervisor
> > log doesn't show any relevant errors or other messages. Then if I
> > don't install xenvif and xennet in my HVM, the problem goes away. I
> > *think* the hang only occurs with a debug build but I need to verify t
> ha
> > t.
> >
> > Also the "upcalls not enabled" error might be a red herring. I added
> > some more diagnostic output to xen.sys and apparently this occurs even
> > during normal HVM boot:
> >
> > XENBUS|EvtchnInterruptEnable: ====>
> > XEN|HvmSetEvtchnUpcallVector: errno -38
> > XEN|HvmSetEvtchnUpcallVector: errno -38
> >
> > Then again, during a normal boot (without xenvif/xennet) EvtchnBind
> > doesn't fail anywhere...
> >
> > I also noticed a lot of the following even during normal HVM operation
> :
> > XEN|HvmPagetableDying: errno -22
> > ...but it's probably harmless?
> >
> Ah, I guess this might be caused by not having this patch:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=04447f4453c008b36c
> 3e
> 3443f0fc44e66ddd821d
> 
> That would certainly explain "not implemented" errors :)

Yes, you appear to have problems due to an older Xen, but the code *should* 
cope with the lack of that hypercall and fall back to the old HVM param 
mechanism. If XENVIF is relying on EvtchnBind working then that's a bug.

  Paul

> - --
> RafaÅ WojdyÅa
> Qubes Tools for Windows developer
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBAgAGBQJViJfJAAoJEIWi9rB2GrW7ZpgH/ibezCrtXDH5KAQaG+Rj1OG
> g
> lpycAlsxl7VVnVqtyASJnFIAXrDTfu8MYw78oPRQfFR/3V3ly2wI9bjHXHQtxqY5
> VKRM6VKm3KSI6D7S7dxwidBuu0wGc906awScUYr2eo4YE2YevS9tE7gFRBHee
> n8m
> WyqAXGRL2YCxpeknCjKiztqfaLFlD8hg2OF/LMutf1kfr+3akMHDYu6z3DLd930
> W
> 4g3GSnxNFX++aXQRE2navRbi90kerQy188NiuWPW/9OFm/IGoic1vazilqg4d1sr
> JnBaTaurHpBhf52bDF3qZvFwerGRtdgxCgLvrAxsTb+tBGG4synXSYj2/yUyfTQ=
> =Vmwe
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> win-pv-devel mailing list
> win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel
_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel