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

Re: [Xen-devel] xm save -c problem with GPLPV drivers and winxp



On Sun, Dec 16, 2012 at 01:29:51AM -0800, Liu.yi wrote:
> hi,all

Hello,

I added the important keywords to the subject..

-- Pasi

>     I have a winxpsp2 vm with gplpv driver installed. The problem is that
> when I excute "xm save -c winxpsp2 save.bin", the command is excuted
> successfully but the vm hang after issuing a disk operaton.
>     After installing gplpv debug driver, from the qemu log I found vbd
> resume failed, after a while windows issues disk reset command, then vm
> hang.
>     xm debug-keys shows as follows before "xm save -c":
> (XEN)        1 [0/1]: s=3 n=0 d=0 p=72 x=1
> (XEN)        2 [0/0]: s=3 n=0 d=0 p=71 x=0
> (XEN)        3 [0/1]: s=2 n=0 d=0 x=0
> (XEN)        4 [0/0]: s=6 n=0 x=0                   // pdo_event_channel
> (XEN)        5 [0/0]: s=2 n=0 d=0 x=0             // suspend_evtchn
> (XEN)        6 [0/0]: s=3 n=0 d=0 p=73 x=0     // vbd-768 event-channel
> (XEN)        7 [0/0]: s=3 n=0 d=0 p=74 x=0     // vif-0 event-channel
>     xm debug-keys shows as follows after "xm save -c":
> (XEN)        1 [0/1]: s=3 n=0 d=0 p=72 x=1
> (XEN)        2 [0/0]: s=3 n=0 d=0 p=71 x=0
> (XEN)        3 [0/1]: s=2 n=0 d=0 x=0
> (XEN)        4 [0/0]: s=6 n=0 x=0                   // pdo_event_channel
> (XEN)        5 [0/0]: s=2 n=0 d=0 x=0             // suspend_evtchn
> (XEN)        6 [0/0]: s=6 n=0 x=0                   // new pdo_event_channel
> (XEN)        7 [0/0]: s=2 n=0 d=0 x=0             // new suspend_evtchn
> (XEN)        8 [0/0]: s=3 n=0 d=0 p=? x=0       // new vbd-768 event-channel
>                                                               // vif-0
> resume don't start at all because resume hang at vbd
> 
>     blkback and blkif driver seem free their event-channel in
> unbind_from_irqhandler when suspending, so when gplpv driver resumes it
> starts allocing event-channel from 6. The strange things is that gplpv
> driver allocs new pdo_event_channel and suspend_evtchn (6 and 7), the
> previous ones retain active.
>     I tried to unbind the old pdo_event_channel and suspend_evtchn, but
> suspending vm hang. "xm save -c" wokrs if I reuse the old pdo_event_channel
> and suspend_evtchn as follows:
> 
>   in evtchn.c:EvtChn_Init()
>       KeInitializeEvent(&xpdd->pdo_suspend_event, SynchronizationEvent,
> FALSE);
>       if (xpdd->pdo_event_channel == 0) {
>           KdPrint((__DRIVER_NAME "     create new pdo_event_channel\n"));
>           xpdd->pdo_event_channel = EvtChn_AllocIpi(xpdd, 0);
>       }
>   in xenpci_fdo.c:XenPci_ConnectSuspendEvt()
>       if (xpdd->suspend_evtchn == 0) {
>           xpdd->suspend_evtchn = EvtChn_AllocUnbound(xpdd, 0);
>           KdPrint((__DRIVER_NAME "     create new suspend event
> channel\n"));
>       } 
> 
>     The qemu log show vbd and vif resume successfully, vm runs fine.
>     I'm not sure about these modifications to gplpv windows driver. I will
> be grateful for any suggestions, thks.
> 
> 
> 
> --
> View this message in context: 
> http://xen.1045712.n5.nabble.com/xm-save-c-problem-tp5713082.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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