On Fri, 2025-09-12 at 09:50 +0100, Daniel P. Berrangé wrote: > On Fri, Sep 12, 2025 at 04:41:02AM -0400, Michael S. Tsirkin wrote: > > On Fri, Sep 12, 2025 at 05:39:45AM +0200, Filip Hejsek wrote: > > > The goal of this series is to have a resizable terminal into a > > > guest > > > without having to set up networking and using, e.g. ssh. > > > > > > The virtio spec allows a virtio-console device to notify the > > > guest about > > > terminal resizes in the host. Linux Kernel implements the driver > > > part of > > > the spec. This series implement the device part in QEMU. > > > > > > This series adds support for a resizable terminal if a virtio > > > console > > > device is connected to the stdio backend. > > > > > > This series also introduces resize messages that can be sent over > > > QMP to > > > notify QEMU about the size of the terminal connented to some > > > chardev. > > > In the libvirt setting, it will allow to implement a resizable > > > terminal > > > for virsh console and other libvirt clients. > > > > > > This patch series was originally authored by Szymon Lukasz and > > > submitted > > > to qemu-devel about 5 years ago. The previous submission can be > > > found at > > > < > > > https://lists.nongnu.org/archive/html/qemu-devel/2020-06/msg09591. > > > html>. > > > I have updated the patches to be compatible with latest master > > > and made > > > a few small changes of my own, including the addition of Windows > > > support. > > > > > > Probably the most important change I made is the swapping of rows > > > and > > > cols fields in resize messages. I would like to hear some > > > feedback on > > > this change from reviewers. The problem is that for a long time, > > > the > > > Linux kernel used a different field order from what was specified > > > in the > > > virtio spec. The kernel implementation was apparently merged > > > around 2010, > > > while the virtio spec came in 2014, so when a previous version of > > > this > > > patch series was being discussed here on this mailing list in > > > 2020, it > > > was decided that QEMU should match the Linux implementation, and > > > ideally, > > > the virtio spec should be changed. > > > > > > However, recently, the Linux kernel implementation was changed to > > > conform > > > to the spec: > > > <https://git.kernel.org/linus/5326ab737a47278dbd16ed3ee7380b26c70 > > > 56ddd>. > > > As a result, to be compatible with latest kernel releases, QEMU > > > needs to > > > also use the field order matching the specification. I have > > > changed the > > > patch to use the spec-compliant order, so it works correctly with > > > latest > > > kernels now. > > > > > > > Well this is not in any release yet. If you want me to revert that > > one, let me know ASAP. Maximilian? > > > > > That leaves the issue of older kernels. There are about 15 years' > > > worth > > > of kernel versions with the swapped field order, including the > > > kernel > > > currently shipped in Debian stable. The effects of the swapped > > > dimensions > > > can sometimes be quite annoying - e.g. if you have a terminal > > > with > > > 24 rows, this will be interpreted as 24 columns, and your shell > > > may limit > > > line editing to this small space, most of which will be taken by > > > your > > > prompt. The patch series in its current form provides no way to > > > disable > > > the console size functionality, > > > > Well I see the console-size property, no? > > At least in the case of libvirt managed VMs, this series does > nothin by default, as they won't be using the 'stdio' chardev, > they'll require libvirt to first wire up the new QMP command, > and then apps using libvirt to call it. So in that sense, it'll > take a while before the effects are seen by users.
Correct me if I'm wrong on this, but shouldn't the 'pty' chardev also be able to take advantage of the same size change mechanisms as the 'stdio' chardev (receiving SIGWINCH and being able to use the ioctl TIOCGWINSZ)? If so the work for the 'stdio' chardev should probably be replicated for the 'pty' chardev. > > > > so users may end up worse off than if > > > the functionality were not implemented at all. > > > > If we want to keep the Linux patch, the straight forward way is to > > send > > the fix to stable@ then poke at Debian at al to fix their kernels. > > > > Another option is to make the property default to off, have > > management turn it on when guest is up to date. > > > > But it really sounds like we should revert that Linux patch. > > I posted a revert, pls comment. > > What about other non-Linux guest OS that may have correctly > implemented the virtio spec ? > > At least FreeBSD appears to /not/ implemenmt resize at all: > > > https://github.com/freebsd/freebsd-src/blob/main/sys/dev/virtio/console/virtio_console.c#L884 > > Do we have a Windows impl of virtio-console with resize support ? > > Any other places we should check ? > > With regards, > Daniel
