Changelog:

---
v7:
 - Removed some unnecessary definitions from test xml
 - Moved edge case reservation logic to virDomainVirtioSerialAddrAssign
---
v6:
 - Fixed issue with console auto port index starting from 1 instead of 0
---
v5:
 - Added xml tests to tests/qemuxmlconfdata
 - Fixed virito -> virtio typo in commit message
---
v4:
 - Update commit messages
---
v3:
 - Added Reviewed-By
 - Included CI Results Link
---
v2:
 - Split patch into two commits
 - Added fixes tag
---

This libvirt patch series does the following:
1. fixes an issue with virtio console device port auto assignment on virtio-serial buses
2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity
3. Adds tests for virtio console on the vioserial bus

Currently in libvirt, a virtio console device cannot be auto assigned a port number greater than zero on a virtio-serial bus. This leads to port collision errors when adding more than 1 virtio console device on a single virtio-serial bus.

After applying this patch, one can add multiple console ports under a single virtio-serial bus.

Here is a link to CI results for this series: https://gitlab.com/aaronbmalik/libvirt/-/pipelines/2047914492


Aaron M. Brown (3):
  tests: Add console-virtio-serial-autoassign-address tests
  domain_addr.c: Fix virtio console port autoassign on virtio-serial bus
  domain_addr.c: update virtconsole port reservation comment and
    allowZero var

 src/conf/domain_addr.c                        | 51 +++++++++++++-----
 ...rial-autoassign-address.x86_64-latest.args | 42 +++++++++++++++
 ...erial-autoassign-address.x86_64-latest.xml | 54 +++++++++++++++++++
 ...nsole-virtio-serial-autoassign-address.xml | 40 ++++++++++++++
 tests/qemuxmlconftest.c                       |  1 +
 5 files changed, 175 insertions(+), 13 deletions(-)
 create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.x86_64-latest.args
 create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.x86_64-latest.xml
 create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.xml

--
2.39.5 (Apple Git-154)

Ping

On 9/19/25 21:26, Aaron M. Brown wrote:
> Changelog:
> 
> ---
> v7:
>   - Removed some unnecessary definitions from test xml
>   - Moved edge case reservation logic to virDomainVirtioSerialAddrAssign
> ---
> v6:
>   - Fixed issue with console auto port index starting from 1 instead of 0
> ---
> v5:
>   - Added xml tests to tests/qemuxmlconfdata
>   - Fixed virito -> virtio typo in commit message
> ---
> v4:
>   - Update commit messages
> ---
> v3:
>   - Added Reviewed-By
>   - Included CI Results Link
> ---
> v2:
>   - Split patch into two commits
>   - Added fixes tag
> ---


-- 
Mit freundlichen Grüßen/Kind regards
    Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

On Wed, Oct 08, 2025 at 07:47:24 +0200, Boris Fiuczynski wrote:
> Ping

The patches look good to me as they addressed all my comments from
previous version (and sorry for missing this, and the ping).

Any reason why this is still labelled as RFC? Can it be merged?

On 10/24/25 13:49, Peter Krempa wrote:
> On Wed, Oct 08, 2025 at 07:47:24 +0200, Boris Fiuczynski wrote:
>> Ping
> 
> The patches look good to me as they addressed all my comments from
> previous version (and sorry for missing this, and the ping).
> 
> Any reason why this is still labelled as RFC? Can it be merged?
> 

Hi Peter,
I would appreciate you merging it.
The RFC seems to be an oversight.

-- 
Mit freundlichen Grüßen/Kind regards
    Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

On 10/24/25 13:49, Peter Krempa wrote:

> The patches look good to me as they addressed all my comments from
> previous version (and sorry for missing this, and the ping).
>
> Any reason why this is still labelled as RFC? Can it be merged?


On 10/24/25 8:29 AM, Boris Fiuczynski wrote:

>
> Hi Peter,
> I would appreciate you merging it.
> The RFC seems to be an oversight.

Hi all, I labelled these patches as RFC in case there were any 
additional changes requested. If not, it is ready to merge.

On Fri, Oct 24, 2025 at 10:47:11 -0400, Aaron Brown wrote:
> On 10/24/25 13:49, Peter Krempa wrote:
> 
> > The patches look good to me as they addressed all my comments from
> > previous version (and sorry for missing this, and the ping).
> > 
> > Any reason why this is still labelled as RFC? Can it be merged?
> 
> 
> On 10/24/25 8:29 AM, Boris Fiuczynski wrote:
> 
> > 
> > Hi Peter,
> > I would appreciate you merging it.
> > The RFC seems to be an oversight.
> 
> Hi all, I labelled these patches as RFC in case there were any additional
> changes requested. If not, it is ready to merge.

Please note for future patches, the RFC label is used for patches where
you are unsure about your design (and e.g. didn't fully implement
everything) or have a dependancy that's still blocking them.

In general anything that is not really supposed to be merged in the
proposed form.

On 10/30/25 07:51, Peter Krempa via Devel wrote:
> On Fri, Oct 24, 2025 at 10:47:11 -0400, Aaron Brown wrote:
>> On 10/24/25 13:49, Peter Krempa wrote:
>>
>>> The patches look good to me as they addressed all my comments from
>>> previous version (and sorry for missing this, and the ping).
>>>
>>> Any reason why this is still labelled as RFC? Can it be merged?
>>
>>
>> On 10/24/25 8:29 AM, Boris Fiuczynski wrote:
>>
>>>
>>> Hi Peter,
>>> I would appreciate you merging it.
>>> The RFC seems to be an oversight.
>>
>> Hi all, I labelled these patches as RFC in case there were any additional
>> changes requested. If not, it is ready to merge.
> 
> Please note for future patches, the RFC label is used for patches where
> you are unsure about your design (and e.g. didn't fully implement
> everything) or have a dependancy that's still blocking them.
> 
> In general anything that is not really supposed to be merged in the
> proposed form.
> 

This series might have fallen through the cracks.
It can be merged unless Aaron is supposed to resend it without RFC.
Please let Aaron know what to do. Thanks.

-- 
Mit freundlichen Grüßen/Kind regards
    Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

On Mon, Nov 24, 2025 at 15:01:22 +0100, Boris Fiuczynski wrote:
> On 10/30/25 07:51, Peter Krempa via Devel wrote:
> > On Fri, Oct 24, 2025 at 10:47:11 -0400, Aaron Brown wrote:
> > > On 10/24/25 13:49, Peter Krempa wrote:
> > > 
> > > > The patches look good to me as they addressed all my comments from
> > > > previous version (and sorry for missing this, and the ping).
> > > > 
> > > > Any reason why this is still labelled as RFC? Can it be merged?
> > > 
> > > 
> > > On 10/24/25 8:29 AM, Boris Fiuczynski wrote:
> > > 
> > > > 
> > > > Hi Peter,
> > > > I would appreciate you merging it.
> > > > The RFC seems to be an oversight.
> > > 
> > > Hi all, I labelled these patches as RFC in case there were any additional
> > > changes requested. If not, it is ready to merge.
> > 
> > Please note for future patches, the RFC label is used for patches where
> > you are unsure about your design (and e.g. didn't fully implement
> > everything) or have a dependancy that's still blocking them.
> > 
> > In general anything that is not really supposed to be merged in the
> > proposed form.
> > 
> 
> This series might have fallen through the cracks.
> It can be merged unless Aaron is supposed to resend it without RFC.
> Please let Aaron know what to do. Thanks.

Eh, I was about to push it at the start of this dev cycle. I've even
said as much to Aaron in my reply to Aarons private message to me. I
don't know what happened because I didn't even find my branch where I
had the patches applied (which would normally mean that they are
pushed).

Anyways I've found them in the reflog including my R-b tags ... so I'll
push them after CI finishes:

https://gitlab.com/pipo.sk/libvirt/-/pipelines/2176162602

Series:

Reviewed-by: Peter Krempa <pkrempa@redhat.com>