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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


Reply via email to