Re: [PATCH v6 00/12] virtio-console: notify about the terminal size

[Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>]

On Tue, 2026-06-09 at 13:13 +0200, Filip Hejsek wrote:
> On Tue, 2026-06-09 at 10:26 +0200, Maximilian Immanuel Brandtner
> wrote:
> > On Tue, 2026-06-09 at 04:09 -0400, Michael S. Tsirkin wrote:
> > > On Tue, Jun 09, 2026 at 10:02:40AM +0200, Maximilian Immanuel
> > > Brandtner wrote:
> > > > What's the status of this series? It seems to me to have
> > > > somewhat
> > > > stalled, because of the virtio resize event discrepancy that
> > > > has
> > > > been
> > > > adressed by backporting the relevant patch. At this point it's
> > > > been
> > > > almost 6 months since any changes have been made to this patch-
> > > > set,
> > > > even though at this point it would have to be refactored to
> > > > address
> > > > changes that have been made to QEMU since. Has progress on this
> > > > patch-
> > > > set just stalled or are there any remaining concerns about the
> > > > implementation of this patch-set I'm unaware of?
> > > > 
> > > > Kind regards,
> > > > Max Brandtner
> > > 
> > > Whom are you asking?
> > > There were comments on patches 7 and 8 and Filip seems to have
> > > indicated
> > > he intends to address them, and even posted diffs.
> > > So now, I expect v7 with that.
> > I suppose Filip for the most part. It's just that close to 6 months
> > of
> > inactivity is quite a while and sometimes as other stuff happens
> > people
> > can forget about a patch-series.
> > 
> > Kind regards,
> > Max Brandtner
> 
> Hi all,
> 
> Sorry, I did indeed forget about the series.
> 
> From what I remember, I was trying to address an issue with the size
> not being updated after a migration, and it turned out fixing this
> required adding the current size to the migration stream (in order to
> avoid sending unnecessary resize events when the size doesn't change,
> which MST pointed out would add guest performance overhead).
> 
> However, since virtio console serialization still uses save/load
> methods rather than VMState macros, I couldn't simply add a
> subsection,
> so I wasn't quite sure how to proceed. It seemed like the right thing
> to do was to migrate virtio-console to VMState, but that would have
> taken more effort than I was willing to put in at that moment. And
> then
> some other stuff happened in my life and now here we are.
> 
> So anyway, in order to make progress on this, I see two approaches:
> 
> 1. Just bump the migration stream version. Makes the loading code
> more
> convoluted due to version checks and increases tech dept for future
> VMState migration, but shouldn't be that hard to do.
> 
> 2. Do the VMState migration now. This is complicated by the fact the
> on
> load, some of the state shouldn't be restored back into the field
> that
> was saved, but instead should be compared and the guest notified if
> it
> is different. I'm also not quite sure how hard it will be to preserve
> migration stream compatibility.
> 
> Which one would be preferable to do?
> 
> Kind regards,
> Filip Hejsek

I have another patch in the pipeline to add resize support for another
chardev backend. Would the migration issue affect any chardev backend
that wants to support resizing or is it specific to virtio? I don't
have a strong opinion either way regarding virtio-console, but I'd be
quite interested to see the generic chardev resizing code rebased
against the latest upstream QEMU sooner rather than later.

Kind regards,
Max Brandtner