On 3/14/19 10:52 AM, Oleksandr Andrushchenko wrote:Ah, the difference can be of the way we get the guest enter
On 3/14/19 4:47 PM, Boris Ostrovsky wrote:
On 3/14/19 9:17 AM, Oleksandr Andrushchenko wrote:Exactly, if you take a look at the .resume callback as it is now
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>What do you mean? Are you saying that after resume you lose
Currently on driver resume we remove all the network queues and
destroy shared Tx/Rx rings leaving the driver in its current state
and never signaling the backend of this frontend's state change.
This leads to the number of consequences:
- when frontend withdraws granted references to the rings etc. it
cannot
ÂÂ be cleanly done as the backend still holds those (it was not told to
ÂÂ free the resources)
- it is not possible to resume driver operation as all the
communication
ÂÂ means with the backned were destroyed by the frontend, thus
ÂÂ making the frontend appear to the guest OS as functional, but
ÂÂ not really.
connectivity?
what it does it destroys the rings etc. and never notifies the backend
of that, e.g. it stays in, say, connected state with communication
channels destroyed. It never goes into any other Xen bus state, so
there is
no way its state machine can help recovering.
My tree is about a month old so perhaps there is some sort of regression
but this certainly works for me. After resume netfront gets
XenbusStateInitWait from backend which causes xennet_connect().
Thank you,
-boris