On 22 May 2018 at 20:06, Cédric Le Goater <[email protected]> wrote: > On 05/22/2018 07:37 PM, Peter Maydell wrote: >> This is sufficient that a save-and-reload while the romulus-bmc >> machine is in the bootloader will work. On the other hand if >> I do a save-and-reload after the kernel has started booting >> then we get the classic "guest hang after reload", so some >> state is still not being transferred somewhere (probably in >> a device in the machine model?) > > I see the problem. Bizarre.
Usually it means that something in the path from timer device through to the CPU has failed to save-and-reload the state that it needs to, so that when the timer fires post-reload it doesn't actually cause a CPU interrupt. You can probably debug by putting a breakpoint on whatever looks like a likely timer device's 'set the irq line' function and stepping through to figure out what's happening. (You're not using trustzone, are you? I know of a bug with migration of cpus with TZ enabled which I'm probably going to look at later this week) thanks -- PMM
