Patch posted on the list:

https://listman.redhat.com/archives/libvir-list/2023-June/240148.html

To POST:

commit 1c7335add9e28637d8a8b5039f487e5dc6a591c2
Author:     Michal Prívozník <mprivozn>
AuthorDate: Thu Jun 1 10:37:04 2023 +0200
Commit:     Michal Prívozník <mprivozn>
CommitDate: Thu Jun 1 14:25:08 2023 +0200

    qemu_passt: Format portForward device even without address
    
    It's almost like we've anticipated this. Our XML parser and
    formatter handles @address and @dev attributes of <portForward/>
    element completely independent of each other. And as of commit
    2023_03_29.b10b983~3 passt allows handling these two separately
    too. All that's left is generate the cmd line according to this
    new fact.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2210287
    Signed-off-by: Michal Privoznik <mprivozn>
    Reviewed-by: Ján Tomko <jtomko>

v9.4.0-3-g1c7335add9

Hi Michal, the vm can not start successfully(See S3 below). Maybe it depends on a new passt build. Could you please help to confirm? Thank you!

S1: with both dev and address:
$ virsh dumpxml test1 --xpath //interface 
<interface type="user">
  <mac address="52:54:00:26:44:e5"/>
  <source dev="eno1"/>
  <portForward proto="tcp" dev="eno1" address='10.73.178.71'>
    <range start="41335"/>
  </portForward>
  <model type="virtio"/>
  <backend type="passt"/>
  <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>

will come up with:
$ ps aux | grep '/usr/bin/passt'
test       13544  0.0  0.2  76344 38124 ?        Ss   01:20   0:00 /usr/bin/passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/2-test1-net0.socket --mac-addr 52:54:00:26:44:e5 --pid /run/user/1000/libvirt/qemu/run/passt/2-test1-net0-passt.pid --interface eno1 --tcp-ports 10.73.178.71%eno1/41335

S2: only address
 <portForward proto="tcp" address='10.73.178.71'>
    <range start="41335"/>
  </portForward>

VM start successfully and the passt process is like this:
$ ps aux | grep '/usr/bin/passt'
test       13622  0.0  0.2  76344 38828 ?        Ss   01:21   0:00 /usr/bin/passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/3-test1-net0.socket --mac-addr 52:54:00:26:44:e5 --pid /run/user/1000/libvirt/qemu/run/passt/3-test1-net0-passt.pid --interface eno1 --tcp-ports 10.73.178.71/41335

S3: only dev, vm can not start successfully
<portForward proto="tcp" dev="eno1">
    <range start="41335"/>
  </portForward>

$ virsh start test1
error: Failed to start domain 'test1'
error: internal error: Child process (/usr/bin/passt --one-off --socket /run/user/1000/libvirt/qemu/run/passt/4-test1-net0.socket --mac-addr 52:54:00:26:44:e5 --pid /run/user/1000/libvirt/qemu/run/passt/4-test1-net0-passt.pid --interface eno1 --tcp-ports %eno1/41335) unexpected exit status 1: Invalid port specifier %eno1/41335

This BZ (it's pre-verification actually) is blocking libvirt packages from
making it into a RHEL compose. Could this be pre-verified earlier than after
the passt rebase in mid August? For example using passt from upstream or using
a scratch build (aka rebase pre-release) or something similar?

Test with upstream passt and libvirt, the result is as expected:
# rpm -q passt libvirt
passt-g023d684-1.x86_64
libvirt-9.5.0-3.el9.x86_64

# getenforce 
Permissive

1) with address and interface:
# virsh dumpxml rhel --xpath //portForward
<portForward proto="tcp" address="10.73.178.37" dev="eno1">
  <range start="41335"/>
</portForward>

the passt cmdline:
# ps aux | grep 'usr/bin/passt' | grep -v grep 
qemu        5574  0.0  0.0  72936 37628 ?        Ss   02:54   0:00 /usr/bin/passt --one-off --socket /run/libvirt/qemu/passt/7-rhel-net0.socket --mac-addr 52:54:00:49:84:12 --pid /run/libvirt/qemu/passt/7-rhel-net0-passt.pid --interface eno1 --tcp-ports 10.73.178.37%eno1/41335

2) with address only:
# virsh dumpxml rhel --xpath //portForward
<portForward proto="tcp" address="10.73.178.37">
  <range start="41335"/>
</portForward>

the passt cmd line:
# ps aux | grep 'usr/bin/passt' | grep -v grep 
qemu        5692  0.0  0.0  72932 36628 ?        Ss   02:55   0:00 /usr/bin/passt --one-off --socket /run/libvirt/qemu/passt/8-rhel-net0.socket --mac-addr 52:54:00:49:84:12 --pid /run/libvirt/qemu/passt/8-rhel-net0-passt.pid --interface eno1 --tcp-ports 10.73.178.37/41335

3) with interface only:
# virsh dumpxml rhel --xpath //portForward
<portForward proto="tcp" dev="eno1">
  <range start="41335"/>
</portForward>

the passt cmdline:
# ps aux | grep 'usr/bin/passt' | grep -v grep 
qemu        5779  0.0  0.0  72932 36632 ?        Ss   02:56   0:00 /usr/bin/passt --one-off --socket /run/libvirt/qemu/passt/9-rhel-net0.socket --mac-addr 52:54:00:49:84:12 --pid /run/libvirt/qemu/passt/9-rhel-net0-passt.pid --interface eno1 --tcp-ports %eno1/41335

Test with lastest passt downstream build, the result is as expected.
libvirt-9.5.0-5.el9.x86_64
passt-0^20230818.g0af928e-4.el9.x86_64
passt-selinux-0^20230818.g0af928e-4.el9.noarch

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: libvirt security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:6409