]> git.ipfire.org Git - thirdparty/qemu.git/commit
serial: reset thri_pending on IER writes with THRI=0
authorPaolo Bonzini <pbonzini@redhat.com>
Fri, 12 Dec 2014 09:17:08 +0000 (10:17 +0100)
committerMichael Roth <mdroth@linux.vnet.ibm.com>
Mon, 23 Feb 2015 00:03:34 +0000 (18:03 -0600)
commite54bcad901f4891dd5c3bf72e199175a23944214
tree1dec7282961d47cb940b3773c3ec4483018bd901
parente1ce0c3cb7c99e71feb001e392489aa333e87f3c
serial: reset thri_pending on IER writes with THRI=0

This is responsible for failure of migration from 2.2 to 2.1, because
thr_ipending is always one in practice.

serial.c is setting thr_ipending unconditionally.  However, thr_ipending
is not used at all if THRI=0, and it will be overwritten again the next
time THRE or THRI changes.  For that reason, we can set thr_ipending to
zero every time THRI is reset.

There is disagreement on whether LSR.THRE should be resampled when IER.THRI
goes from 1 to 1.  This patch does not touch the code, leaving that for
QEMU 2.3+.

This has no semantic change and is enough to fix migration in the common
case where the interrupt is not pending or is reported in IIR.  It does not
change the migration format, so 2.2.0 -> 2.1 will remain broken but we
can fix 2.2.1 -> 2.1 without breaking 2.2.1 <-> 2.2.0.

The case that remains broken (the one in which the subsection is strictly
necessary) is when THRE=1, the THRI interrupt has *not* been acknowledged
yet, and a higher-priority interrupt comes.  In this case, you need the
subsection to tell the source that the lower-priority THRI interrupt is
pending.  The subsection's breakage of migration, in this case, prevents
continuing the VM on the destination with an invalid state.

Cc: qemu-stable@nongnu.org
Reported-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 4e02b0fcf5c97579d0d3261c80c65abcf92870fe)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
hw/char/serial.c