On Tue, 2026-01-20 at 10:20 +0000, Daniel P. Berrangé wrote:
> On Tue, Jan 20, 2026 at 11:16:51AM +0100, Filip Hejsek wrote:
> > On Tue, 2026-01-20 at 10:10 +0000, Daniel P. Berrangé wrote:
> > > On Tue, Jan 20, 2026 at 11:07:16AM +0100, Filip Hejsek wrote:
> > > > On Tue, 2026-01-20 at 09:54 +0000, Daniel P. Berrangé wrote:
> > > > > On Tue, Jan 20, 2026 at 10:50:04AM +0100, Filip Hejsek wrote:
> > > > > > On Mon, 2026-01-19 at 04:27 +0100, Filip Hejsek wrote:
> > > > > > > Implement the part of the virtio spec that allows to notify the 
> > > > > > > virtio
> > > > > > > driver about terminal resizes. The virtio spec contains two 
> > > > > > > methods to
> > > > > > > achieve that:
> > > > > > > 
> > > > > > > For legacy drivers, we have only one port and we put the terminal 
> > > > > > > size
> > > > > > > in the config space and inject the config changed interrupt.
> > > > > > > 
> > > > > > > For multiport devices, we use the control virtqueue to send a 
> > > > > > > packet
> > > > > > > containing the terminal size. Note that old versions of the Linux 
> > > > > > > kernel
> > > > > > > used an incorrect order for the fields (rows then cols instead of 
> > > > > > > cols
> > > > > > > then rows), until it was fixed by commit 
> > > > > > > 5326ab737a47278dbd16ed3ee7380b26c7056ddd.
> > > > > > > 
> > > > > > > As a result, when using a Linux kernel older than 6.15, the 
> > > > > > > number of rows
> > > > > > > and columns will be swapped.
> > > > > > > 
> > > > > > > Based on a patch originally written by Szymon Lukasz 
> > > > > > > <[email protected]>,
> > > > > > > but partially rewritten to fix various corner cases.
> > > > > > > 
> > > > > > > Signed-off-by: Szymon Lukasz <[email protected]>
> > > > > > > Signed-off-by: Filip Hejsek <[email protected]>
> > > > > > > ---
> > > > > > >  hw/char/trace-events              |  1 +
> > > > > > >  hw/char/virtio-serial-bus.c       | 76 
> > > > > > > +++++++++++++++++++++++++++++++++++++--
> > > > > > >  hw/core/machine.c                 |  4 ++-
> > > > > > >  include/hw/virtio/virtio-serial.h |  5 +++
> > > > > > >  4 files changed, 83 insertions(+), 3 deletions(-)
> > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > > diff --git a/include/hw/virtio/virtio-serial.h 
> > > > > > > b/include/hw/virtio/virtio-serial.h
> > > > > > > index 60641860bf..bda6d5312a 100644
> > > > > > > --- a/include/hw/virtio/virtio-serial.h
> > > > > > > +++ b/include/hw/virtio/virtio-serial.h
> > > > > > > @@ -145,6 +145,9 @@ struct VirtIOSerialPort {
> > > > > > >      bool host_connected;
> > > > > > >      /* Do apps not want to receive data? */
> > > > > > >      bool throttled;
> > > > > > > +
> > > > > > > +    /* Terminal size reported to the guest.  Only used for 
> > > > > > > consoles. */
> > > > > > > +    uint16_t cols, rows;
> > > > > > >  };
> > > > > > 
> > > > > > I found a bug: after a migration, the guest is not informed about 
> > > > > > the
> > > > > > new console size. I see two ways to fix this: either add the cols 
> > > > > > and
> > > > > > rows fields to the migration stream, or always send the console 
> > > > > > size to
> > > > > > the guest after migration, even if it might not have changed. Which 
> > > > > > do
> > > > > > you prefer? Modifying the migration stream is somewhat annoying,
> > > > > > because both versions will have to be supported, and also the device
> > > > > > still uses legacy save/load functions rather than VMState.
> > > > > 
> > > > > On the backend side, I'd consider migration to be equivalent to 
> > > > > closing
> > > > > and re-opening the backend character device. That should imply sending
> > > > > a resize event on  migration completion. I'm surprised the chardev on
> > > > > the dst isn't already triggering that when it gets connected, but 
> > > > > perhaps
> > > > > that is too early & getting lost ?
> > > > 
> > > > The virtio device caches the size and doesn't send a resize message if
> > > > the size hasn't actually changed.
> > > 
> > > If the size on the dest has not changed vs the size on the src, that's
> > > fine surely ? We only need to tell the guest a new size if the dst
> > > was different from the source after migration 
> > 
> > The current size is compared against previous size on the *dst*. We
> > don't know the size on the src, because it is not sent in the migration
> > stream.
> 
> Oh, I see what you mean. In that case we should probably use a .post_load
> hook to invalidate the dst cached size in some manner, so that the next
> update from the backend is forced to be sent to the guest.

I think just sending the cached size is simpler.

Best regards,
Filip

Reply via email to