From: "Michael S. Tsirkin" <mst@redhat.com>
To: Weqaar Janjua <weqaar.janjua@packetfive.com>
Cc: qemu-devel@nongnu.org, kraxel@redhat.com,
peter.maydell@linaro.org, pierrick.bouvier@oss.qualcomm.com,
jasowangio@gmail.com, pbonzini@redhat.com, farosas@suse.de,
lvivier@redhat.com, marcel.apfelbaum@gmail.com,
peterx@redhat.com, lizhijian@fujitsu.com,
odaki@rsg.ci.i.u-tokyo.ac.jp
Subject: Re: [PATCH v3 0/6] hw: Add Cnuas virtual devices
Date: Sat, 31 Oct 2026 13:54:08 -0400 [thread overview]
Message-ID: <20261031135234-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20261031120516.2846639-1-weqaar.janjua@packetfive.com>
On Sat, Oct 31, 2026 at 12:05:14PM +0000, Weqaar Janjua wrote:
> On Fri, Oct 30, 2026 at 07:19:05PM -0400, Michael S. Tsirkin wrote:
> > 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.
>
> Thanks Michael, that is a helpful pointer.
>
> The intended use of the Cnuas emulated PCIe devices is the reason they
> were not designed as virtio devices.
>
> Cnuas is intended for teaching and research of Open Compute ORV3
> (and future versions as it evolves) rack-scale data center systems, where the
> PCIe devices and their drivers are what is being studied. CnuasNIC and
> CnuasGPU are small, fully documented PCIe devices in the spirit of
> edu, but with production-like features such as configurable link speed and
> width, a 64-bit prefetchable BAR (CnuasGPU), and a switch transport
> that joins several guests into one fabric. Their guest drivers are
> full netdev and RDMA core drivers that run rping, perftest and QEMU
> RDMA migration unmodified. Just to clarify these aren't edu extensions
> because they are different PCI classes (network and co-processor), and
> edu's fixed register map is used by existing course material. My concern with
> virtio device is that it would hide the layer we want people to work with.
People being the students?
> Also, that in the ORV3 rack model, each sled carries its own NIC and accelerator
> as separate PCIe functions with their own driver, next to the virtio
> devices the guest uses for its disk and management network.
>
> I understand that a virtio-rdma device could definitely be useful in its own right,
> I am happy to look at it separately since the CnuasSwitch backend could serve
> both. If you are ok with it, for this series I would like to keep the devices as
> they are, in the same spirit as the other QEMU-only devices in the 1b36 range, and
> keep looking for a reviewer for patches 2 and 3 (Jason, Peter, Zhijian, Akihiko,
> any of you?).
>
> Thanks,
>
> Weqaar
--
MST
next prev parent reply other threads:[~2026-10-31 17:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 20:23 [PATCH v3 0/6] hw: Add Cnuas virtual devices Weqaar Janjua
2026-09-29 20:23 ` [PATCH v3 1/6] pci: Add device ID for CnuasNIC Weqaar Janjua
2026-09-30 7:00 ` Gerd Hoffmann
2026-09-29 20:23 ` [PATCH v3 2/6] hw/net: Add Cnuas virtual network adapter Weqaar Janjua
2026-09-29 20:23 ` [PATCH v3 3/6] tests/qtest: Add Cnuas virtual network adapter tests Weqaar Janjua
2026-09-29 20:23 ` [PATCH v3 4/6] pci: Add device ID for CnuasGPU Weqaar Janjua
2026-09-30 7:00 ` Gerd Hoffmann
2026-09-29 20:23 ` [PATCH v3 5/6] hw/misc: Add CnuasGPU virtual accelerator Weqaar Janjua
2026-09-29 20:23 ` [PATCH v3 6/6] tests/qtest: Add CnuasGPU tests Weqaar Janjua
2026-10-16 15:32 ` [PATCH v3 0/6] hw: Add Cnuas virtual devices Weqaar Janjua
2026-10-27 8:07 ` Weqaar Janjua
2026-10-27 10:46 ` Michael S. Tsirkin
2026-10-29 11:57 ` Weqaar Janjua
2026-10-29 17:50 ` Michael S. Tsirkin
2026-10-29 19:42 ` Weqaar Janjua
2026-10-30 23:19 ` Michael S. Tsirkin
2026-10-31 12:05 ` Weqaar Janjua
2026-10-31 17:54 ` Michael S. Tsirkin [this message]
2026-10-31 18:58 ` Weqaar Janjua
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261031135234-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=farosas@suse.de \
--cc=jasowangio@gmail.com \
--cc=kraxel@redhat.com \
--cc=lizhijian@fujitsu.com \
--cc=lvivier@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=pierrick.bouvier@oss.qualcomm.com \
--cc=qemu-devel@nongnu.org \
--cc=weqaar.janjua@packetfive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.