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