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

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

On Thu, Oct 29, 2026 at 07:42:24PM +0000, Weqaar Janjua wrote:
> On Thu, Oct 29, 2026 at 01:50:11PM -0400, Michael S. Tsirkin wrote:
> > 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?
> 
> No, it is not a physical device. There is no CnuasNIC or CnuasGPU
> hardware; both exist only as virtual devices, the QEMU device models
> in this series. Think of CnuasNIC as veth or rxe for RDMA, but
> presented to the guest as a PCI device so the full driver, verbs and
> RDMA CM path runs unmodified. The Cnuas project (cnuas.io) emulates
> the rest of the RDMA subsystem around it, including a RoCEv2 and
> InfiniBand switch. CnuasGPU is the same idea for an accelerator.
> 
> The register interfaces are defined by the models themselves and
> documented in docs/specs/cnuas-vnic.rst (patch 2) and
> docs/specs/cnuasgpu.rst (patch 5), with more detail in the
> datasheets at:
> 
>   https://cnuas.io/cnuas/docs/datasheets/CnuasNIC_Datasheet/
>   https://cnuas.io/cnuas/docs/datasheets/CnuasGPU_Datasheet/
> 
> So this is the same situation as other QEMU-specific devices in the
> 1b36 range, for example pvpanic-pci (1b36:0011) and the emulated UFS
> host controller (1b36:0013), which also have upstream Linux drivers.
> That is why I asked Gerd for IDs from the QEMU range. If we were to
> build hardware, it would use our own PCI vendor ID, not 1b36.
> 
> The "RDMA network adapter" wording may have suggested otherwise. It is
> an RoCEv2 adapter in the sense that a Linux guest sees a normal RDMA
> device, but the wire side is a socket to a user-space switch process,
> not a real NIC. I can make "virtual" more explicit in the commit
> messages and docs if that helps.
> 
> Thanks,
> 
> Weqaar

I see. Then a simple way for you to get some eyes on this, and a path
towards upstreaming, could be to try and add this rdma functionality
in the virtio spec.

Interface changes might be required during the standardization
process.

-- 
MST