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
