Re: [Qemu-devel] [PATCH v3 1/4] serial: reset thri_pending on IER writes with THRI=0

[Paolo Bonzini]

On 15/12/2014 11:46, Dr. David Alan Gilbert wrote:
> I can see this causes the thr_ipending to be 0 more of the time, but I don't
> see why it's sufficient.
> 
> If the transmitter has just transmitted it's last byte, then thr_ipending is 
> set
> true by serial_xmit, however if there is a higher priority interrupt then
> serial_update_irq would set tmp_iir to something other than THRI,
> so I think serial_thr_ipending_needed  would return true and write the
> subsection.

It's not sufficient in all cases, and it cannot be.  If we could always
reconstruct the state, the subsection would not be necessary at all.
Subsections can be used for two things:

- stuff that was not supported in the previous release, and thus would
always be zero if you can start up the machine on the older release
(with old machine type, no new devices or properties or CPU models).
This is easy, but unfortunately not what this patch does.

- stuff that was migrated wrong in the previous release.  Here, the game
to play with the "needed" and "post_load" functions is to find a
good-enough approximation of missing state from migrated state.  This is
what the thr_ipending subsection does: thr_ipending is approximated by
"is the highest-priority active interrupt the THRI interrupt?"

So, in the case you mentioned 2.1->2.1 migration would have
malfunctioned.  The THRI would have been dropped after acknowledging the
higher priority interrupt, and probably the guest driver would have hung
(at least in the case of Windows).  So, in this case 2.2->2.1 migration
should fail, which the subsection achieves.

There are other examples of this in IDE, where PIO state was not
migrated.  Very early migration (during BIOS) would then hung the VM.
The fix is to break backwards migration in this case, unfortunately you
can't have it both ways. :(

Paolo