On 05/22/2018 09:26 PM, Peter Maydell wrote:
> On 22 May 2018 at 20:06, Cédric Le Goater <c...@kaod.org> 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.
OK. I will take a look.
What is bizarre is that the romulus-bmc and the palmetto-bmc
machines use the same timer controller model and the same Linux
driver. So only the CPU type would differ.
> (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)
The PSR is :
PSR=20000093 --C- A S svc32
'S' for secure. Is that also trustzone ?
Thanks,
C.
