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. > > > > > Nothing at all - is in no difference from current QEMU behaviour. > > > > As I said, that's not possible with the current semantics of the > > resize > > command, as we would need to know upfront whether it is going to be > > used. > > > > To get the exact same behavior as current QEMU, we would need to > > add > > some way to inform QEMU whether we want to use the resize command > > (e.g. > > device property). > > That is usually unknowable at the time we spawn QEMU. > > I'd say that the common case is for guests to get given a console > connected to a UNIX socket. Most of the time the console will not > be used. If it is, then we've no idea whether the client will be > something virtualization-unaware like a plain 'socat', or something > virtualization-aware like libvirt's 'virsh console'. > > > Even then, depending on how you interpret the virtio spec, there > > would > > be a problem with multiport devices if port 0 didn't support size, > > but > > another port did. Not providing port 0 size can only be done by not > > offering the size feature bit, and then the question is, can you > > still > > send resize events for the other ports? The spec does not say > > either > > way. > > > > Note that getting the exact same behavior as current QEMU is still > > possible by disabling the console-size property on the virtio- > > serial > > device (but it applies to all ports). > > Yes, it seems like the spec ties our hands here wrt multiple ports. > > I didn't apprepreciate in my previous review that integrating this > support > into QEMU was going to imply us /always/ informing the guest about > the > requested console size for all ports, regardless of the backend. > > I had been under the belief that we were only going to pass size info > to > the guest, if the chardev was 'stdio', and for all other chardev > backends > no size info would be passed unless we had issued the QMP resize > command. > > That we will always pass size info the guest regardless of the > backend, > across all ports, changes my view about whether it is reasonable to > enable resize by default given the known Linux guest bug. > > The impact of the guest bug is just about tolerable if we were only > going > to enable passing size information when the user had chosen 'stdio' > backend > as that is relatively rarely used and mostly by ad-hoc dev usage > where it > is perhaps easier for users to get a fixed guest kernel. > > If we enable this for all ports though, regardless of backend, then I > think > we're going to cause too much pain for users with the inverted > rows/cols, > as its going to apply in every single deployment of QEMU using > virtioconsole. > > So IMHO we cannot enable this without explict user opt-in. > > With regards, > Daniel
