Re: [PATCH] Revert "virtio_console: fix order of fields cols and rows"

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

On Mon, 2025-09-15 at 23:37 +0200, Filip Hejsek wrote:
> Hi,
> 
> On Mon, 2025-09-15 at 18:44 +0200, Maximilian Immanuel Brandtner
> wrote:
> > [...]
> > As I already mentioned in the QEMU discussion, I proposed the fix,
> > because I was working on a similar implementation to bring resizing
> > to
> > QEMU.
> 
> I couldn't find any mention of your implementation on the QEMU ML.
> 
> > Unfortunately, the patch-set was stuck in limbo for a while and
> > now that someone else has picked up the slack, I've descided that
> > it's
> > better to contribute to the patch-set that is upstream instead of
> > sending a competing patch-set that does the same thing.
> 
> Would it be OK for me to take a look at your WIP patches? I would
> like
> to see if you did anything differently.
> 

For the stuff I can get clearance for anyways. The tl:dr of what's
different about my patch-set is as follows:
- introduce a new IOResizeHandler instead of using a chr backend event
- dynamically add a QOM-property to every character device that
supports resizing (instead of the qmp-command that you have
implemented)
- guest chardev implementations

I also used a g_unix_signal_source instead of a signal notifier and it
worked during testing, but I prefer your solution

> Also, you mentioned before that you were also working on patches for
> Libvirt. These will still be useful, because I won't be implementing
> that part.
> 

I haven't properly implemented it for libvirt either. The libvirt patch
-set would have to be somewhat sizeable as well as virStream currently
doesn't implement a handle to perform hypervisor specific calls (which
a resize QMP call would be). Accordingly, the virStream implementation
would have to be changed on a deeper level which is why I just didn't
come around to it (I would also need to familiarize myself first with
libvirt more which I haven't done yet).

> > [...]
> > I don't really care if this discrepancy is fixed one way or the
> > other,
> > but it should most definitely be fixed.
> 
> I'm of the same opinion, but if it is fixed on the kernel side, then
> (assuming no device implementation with the wrong order exists) I
> think
> maybe the fix should be backported to all widely used kernels. It
> seems
> that the patch hasn't been backported to the longterm kernels [1],
> which I think Debian kernels are based on.
> 
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/char/virtio_console.c?h=v6.12.47
> 

Then I guess the patch-set should be backported

> > Kind regards,
> > Max Brandtner
> 
> Regards,
> Filip Hejsek