Re: [PATCH v2] char-pty: add support for the terminal size

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

On Thu, 2025-09-18 at 09:59 +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 18, 2025 at 10:54:45AM +0200, Maximilian Immanuel
> Brandtner wrote:
> > On Thu, 2025-09-18 at 09:48 +0100, Daniel P. Berrangé wrote:
> > > On Thu, Sep 18, 2025 at 10:39:28AM +0200, Maximilian Immanuel
> > > Brandtner wrote:
> > > > On Thu, 2025-09-18 at 09:35 +0100, Daniel P. Berrangé wrote:
> > > > > On Wed, Sep 17, 2025 at 08:29:39PM +0200, Filip Hejsek wrote:
> > > > > > On Wed, 2025-09-17 at 18:53 +0100, Daniel P. Berrangé
> > > > > > wrote:
> > > > > > > On Wed, Sep 17, 2025 at 07:11:03PM +0200, Filip Hejsek
> > > > > > > wrote:
> > > > > > > > On Wed, 2025-09-17 at 17:17 +0100, Daniel P. Berrangé
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > We shouldn't send any size info to the guest if the
> > > > > > > > > hsot
> > > > > > > > > backend
> > > > > > > > > does not have it available.
> > > > > > > > 
> > > > > > > > Does that mean sending 0x0, or not sending anything at
> > > > > > > > all?
> > > > > > > > The
> > > > > > > > later
> > > > > > > > is tricky, because for non-multiport devices it's only
> > > > > > > > really
> > > > > > > > possible
> > > > > > > > by not offering the feature bit, but we don't know
> > > > > > > > upfront
> > > > > > > > whether the
> > > > > > > > size command will be used.
> > > > > 
> > > > > What are the semantics in the guest if we sent 0x0 as the
> > > > > size ?
> > > > > AFAICT the virtio spec is silent on what '0x0' means.
> > > > > 
> > > > > It seems like it could conceivably have any behaviour,
> > > > > whether
> > > > > a zero-size console, or a console clamped to 1x1 as a min
> > > > > size,
> > > > > or a console reset to an arbitrary guest default like 80x24.
> > > > 
> > > > During testing the kernel resized the tty to 0x0 if VirtIO
> > > > instructed
> > > > the kernel to resize the tty to 0x0.
> > > 
> > > If the chardev backends are defaulting to 0x0 for everything
> > > except
> > > the 'stdio' backend, then this series is surely going to break
> > > all
> > > existing usage of virtio-console for non-stdio backends ?
> > > 
> > > What am I missing here ?
> > 
> > Most applications fall back to 80x24 if the terminal size is 0x0 so
> > it's not as big of a dealbreaker as you might think.
> 
> I'm not convinced that its a good idea for QEMU to be relying on
> every
> application to be doing that. I can forsee the bug reports from
> situations
> where this doesn't happen and something ends up dividing by zero when
> doing an aspect ratio calculation.  Yes, we could point to the app
> code
> and call it buggy, but I think there's a strong case to be made that
> we
> shouldn't have been sending 0x0 to begin with.
> 
> > However, I think it would be even better if the patch-set could be
> > changed to account for that. After initializing the VirtIO console
> > a
> > resize event could be sent to set the initial size (80x24), which
> > might
> > later be changed or be left as is.
> 
> The problem with QEMU sending 80x24 instead of 0x0 is that the
> majority
> of Linux guests will then treat that as 24x80 due to the historical
> bug
> in Linux drivers. This will probably be even worse than the bugs we
> get
> from sending 0x0.

I agree that this is a much more significant issue and I like your idea
of adding an opt-in parameter to support resizing for the virtio-
console chardev. The smoothest solution would have been a spec-change.

> 
> > If the VIRTIO_CONSOLE_F_SIZE is negotiated(and this feature flag is
> > necessary for multiport resize messages not to be ignored) QEMU is
> > responsible for setting the initial terminal size.
> 
> With regards,
> Daniel