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. > > 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). 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). With regards, Filip
