On Thu, Nov 8, 2018 at 3:22 PM Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > > On Wed 07 Nov 22:36 PST 2018, xiang xiao wrote: > > > On Thu, Nov 8, 2018 at 2:18 PM Bjorn Andersson > > <bjorn.andersson@xxxxxxxxxx> wrote: > > > > > > On Wed 07 Nov 06:25 PST 2018, xiang xiao wrote: > > > > When the crash happen, is it better to destroy and recreate all virtio > > > > device and it’s children(rpmsg device) again to match the remote side state > > > > like the original behavior? > > > > > > > > > > Yes, it's likely that the protocols on top does share some state, so we > > > do not have any choice but to report this up to the virtio device. > > > > > > Removing and re-probing the devices - rather than having some other form > > > of notification of this event - makes the code simpler. > > > > > > > > > But it seems we're trying to re-register the same device the second > > > time, rather than initialize a new one. > > > > > If we use one new here, the old need to be destroyed to avoid the leak. > > Basically, it's become the old approach again. > > > > You're right, for vdevs we must tear them down and bring them up again. > > The reason for introducing the offending commit was for carveouts to > be allocated past the stop() call, so that we can stop the core and > provide a coredump for post mortem debugging. > Why we need stop the remote core before making a coredump? Basically, the coredump is just a series memory copy, it isn't harmful to do it while the remote code is still live.
