diff options
| author | Dr. David Alan Gilbert <dgilbert@redhat.com> | 2017-02-23 13:34:41 +0000 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2017-03-03 16:40:03 +0100 |
| commit | fc3a1fd74fac0e3233060aaaf923fe8ec104b48f (patch) | |
| tree | 636c566b963a95976e3b1cac8185a7b2617887f7 /memory.c | |
| parent | f20e6f8cd42acae9a130b9e0bcd47b0d7e39f253 (diff) | |
| download | qemu-fc3a1fd74fac0e3233060aaaf923fe8ec104b48f.zip qemu-fc3a1fd74fac0e3233060aaaf923fe8ec104b48f.tar.gz qemu-fc3a1fd74fac0e3233060aaaf923fe8ec104b48f.tar.bz2 | |
x86: Work around SMI migration breakages
Migration from a 2.3.0 qemu results in a reboot on the receiving QEMU
due to a disagreement about SM (System management) interrupts.
2.3.0 didn't have much SMI support, but it did set CPU_INTERRUPT_SMI
and this gets into the migration stream, but on 2.3.0 it
never got delivered.
~2.4.0 SMI interrupt support was added but was broken - so
that when a 2.3.0 stream was received it cleared the CPU_INTERRUPT_SMI
but never actually caused an interrupt.
The SMI delivery was recently fixed by 68c6efe07a, but the
effect now is that an incoming 2.3.0 stream takes the interrupt it
had flagged but it's bios can't actually handle it(I think
partly due to the original interrupt not being taken during boot?).
The consequence is a triple(?) fault and a reboot.
Tested from:
2.3.1 -M 2.3.0
2.7.0 -M 2.3.0
2.8.0 -M 2.3.0
2.8.0 -M 2.8.0
This corresponds to RH bugzilla entry 1420679.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20170223133441.16010-1-dgilbert@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'memory.c')
0 files changed, 0 insertions, 0 deletions