Re: [PATCH v3 0/6] hw: Add Cnuas virtual devices

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 29, 2026 at 11:57:06AM +0000, Weqaar Janjua wrote:
> On Tue, Oct 27, 2026 at 06:46:49AM -0400, Michael S. Tsirkin wrote:
> > Sorry I can merge if someone reviews but I just can't take on reviewing
> > a new device right now, I'm buried under AI security reports as it is.
> 
> Thanks Michael, understood, and thank you for offering to merge once
> it is reviewed.
> 
> > I appreciate that you listed yourself as the sole maintainer but you are
> > a first time contributor.
> 
> Fair point. I am happy to be listed as a reviewer instead, or alongside
> an existing maintainer if someone in the net or migration area is
> willing. I will keep supporting the code either way.
> 
> > Maybe Jason can review. Try poking other net device maintainers.
> > Maybe rdma migration guys? if this is useful to test
> > qemu rdma migration then suddenly you have users within the community.
> 
> Thanks for the suggestion, I tried it. Setup: two Linux guests on one
> host, each with a CnuasNIC (1b36:0017 from this series) attached to a
> shared user-space switch, using the in-kernel RDMA stack over RoCEv2.
> 
> - rping over RDMA CM, 1000 iterations per size, data verified with -V
>   (rping -s/-c -a <ip> -C 1000 -S <size> -V), both sides exit 0:
> 
>     size      wall time   per iteration   RDMA READ+WRITE data
>     64 B        1.218 s         1218 us             0.8 Mb/s
>     4096 B      1.172 s         1172 us            55.9 Mb/s
>     32768 B     1.857 s         1857 us           282.4 Mb/s
> 
>   Wall time is measured on the client and includes connect and
>   disconnect.
> - perftest over RDMA CM (ib_send_bw -R, ib_read_lat -R,
>   ib_write_lat -R) passes.
> - QEMU RDMA migration of a nested TCG guest with 512 MiB of RAM filled
>   with random data, source paused, migrate rdma:<ip>:<port>. With QEMU
>   master (29b1dc631d) it completed in 6.4 s at about 675 Mbps with
>   269 ms downtime, and a pmemsave of guest RAM is identical on source
>   and destination.
> 
> So CnuasNIC gives another way to exercise migration/rdma.c on a single
> host without RDMA hardware. The guest driver changes needed for RDMA CM
> will be part of our Linux driver submission (blocked on PCI ID patches 1
> and 4), and I can share the full setup if anyone wants to reproduce it.
> 
> Jason, Peter, Zhijian, Akihiko: would one of you be able to review
> patches 2 and 3 (the CnuasNIC device model and its qtest)?
> 
> > Indeed, next release.
> 
> Agreed for the device models.
> 
> One request on the PCI IDs: patches 1 and 4 only reserve 1b36:0017 and
> 1b36:0018, and both have Gerd's Reviewed-by. Our Linux driver and
> rdma-core provider submissions depend on these IDs, so the device models
> waiting for the next release also holds up that work. Would it be
> acceptable to merge patches 1 and 4 ahead of the device models, for
> 11.2 if there is still time before the soft freeze? If it is easier, I
> can send them as a separate two-patch series rebased on master.
> 
> Thanks,
> 
> Weqaar

Hmm wait a second.  I don't understand. Isn't it a physical device you
are emulating?  Why is it using the Red Hat IDs?


-- 
MST