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. > 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 -- |: 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 :|
