Re: [PATCH v2] char-pty: add support for the terminal size

[Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>]

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