| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Why I cannot reconnect blk backend
>
> Hi,
>
> I am implementing save/restore feature for windows pv driver. After
system
> resumed, my frontend blk driver cannot connect backend. Here is my
work
> flow:
>
> 1, Set frontend state to XenbusStateClosing, then set state to
> XenbusStateClosed. At the end, set frontend state to
> XenbusStateInitiazing.
> 2, Release blk device relevant memory.
> 3, Shutdown xenbus and release relevant memory.
> 4, Call hypercall to let system suspend.
> ......
> (resume)
> 5. Reinit xenbus.
> 6. Get grant table, init share ring, allocate event channel for blk
> device.
> 7. Set frontend state to XenbusStateConnected. <-- got issue here.
>
> When set frontend state to connect, my backend state watcher tell me
that
> backend state changed to closing and then closed.
>
> I am not very family with blk backend driver, so I want to know which
> scenarios cause blk backend state change to closing/closed. Any info I
> gave to xenstore is wrong?
>
> I use xen 3.1.3, win2k3. I can provide me info if you need.
>
Assuming your source is still mostly based on an earlier version of
mine, have a look at the current hg tree - save/restore is all working
there again as of a week or so ago.
It is possible to turn tracing on for xenstore too - under Debian I
added "export XENSTORED_TRACE=1" so it looks like this:
case "$1" in
start)
export XENSTORED_TRACE=1
[ -d "$XENSTORED_RUN_DIR" ] || mkdir -p "$XENSTORED_RUN_DIR"
log_daemon_msg "Starting $DESC" "xend"
start && log_end_msg 0 || log_end_msg 1
;;
That way you can watch exactly what goes on between the frontend and
backend, including all the state transitions.
How are you communicating with the backend driver during restore? In my
first version of xenvbd I relied on the fact that some of the init calls
to the scsiport driver were called at PASSIVE_LEVEL and so it was safe
to make calls to the xenbus routine. Once things are up and running
though, all scsiport code runs at DIRQL (hardware IRQ level) and you
can't call any xenbus code from there as it involves
KeWaitForSingleObject etc.
To work around that I make the pci driver put xenvbd into a mode where
it doesn't process anything (set a flag and fire an irq to xenvbd then
wait for an acknowledgement), and the pci driver itself does all the
xenbus setup for xenvbd, and then enables xenvbd again via the same
mechanism. It works well and the scsiport driver can act more like a
physical hardware device driver - it doesn't need to know anything about
xenbus etc.
Windows is a bit of a pain to work with sometimes - it has better
documentation but its limits are absolutely set in stone!
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home