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

[RafaÅ WojdyÅa <omeg@xxxxxxxxxxxxxxxxxxxxxx>]

On 2015-06-23 10:57, Paul Durrant wrote:
>> -----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
>>
> 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
>>
[Dropping mail signing because inline sigs break formatting badly and
PGP/MIME doesn't work with mailing list footers]

Yeah, this seems to be xenvif-specific (xenvbd works fine). I'm
attaching a full boot log from one such failed start. I'm using my
modified xenbus/xeniface drivers but that shouldn't be a factor here
(can double-check later with an unmodified build).

--
RafaÅ WojdyÅa
Qubes Tools for Windows developer

Attachment: xenvif-boot.7z
Description: Binary data

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