On 16/06/26 06:20PM, Jonathan Cameron wrote:
On Tue, 9 Jun 2026 16:28:31 +0530
Shrihari E S <[email protected]> wrote:
From: Dongjoo Seo <[email protected]>
Implement the Streamlined Virtual Channel (SVC) extended capability
for PCIe ports (Root, Upstream, and Downstream). This capability is
mandatory for enabling Unordered IO (UIO) traffic as per PCIe 6.4
specification [1].
UIO functionality depends on two key prerequisites:
1. SVC support (SVC3 mandatory, SVC4 optional)
2. 256-byte Flit mode support
This patch adds the following experimental properties to PCIe ports:
- x-uio-svc: Enable UIO traffic via SVC3 (mandatory path)
- x-uio-svc-opt: Enable UIO traffic via SVC4 (optional path)
That doesn't feel like naming that will stand the test of time.
I think it needs to mention svc4 in the name. Or I suppose we could
do something with a single x-uio-svc parameter taking values.
Hi Jonathan,
We thought,
- it would be more technical if we add svc3 and svc4 in the
emulation parameters and
- would be readable if we advertise the field as UIO mandatory
SVC (x-uio-svc) and UIO optional SVC (x-uio-svc-opt).
cool will change those to "x-uio-svc3" and "x-uio-svc4" in the
upcoming version.
Thanks.
- x-256b-flit: Enable 256B flit mode required for UIO
Helper functions are included to manage UIO traffic gating and SVC
configuration. This change lays the groundwork for UIO emulation in
QEMU.
[1]: PCIe 6.4 Specification, Table 2-46 (Streamlined Virtual Channel)
I'm currently out of the loop for PCIe specs. So if someone else could
review against spec that would be great.
Signed-off-by: Dongjoo Seo <[email protected]>
Signed-off-by: Shrihari E S <[email protected]>
---
static const TypeInfo xio3130_upstream_info = {
diff --git a/include/hw/pci/pcie_port.h b/include/hw/pci/pcie_port.h
index 1bcc734649..a6b1b8a6cf 100644
--- a/include/hw/pci/pcie_port.h
+++ b/include/hw/pci/pcie_port.h
@@ -37,8 +37,29 @@ struct PCIEPort {
/* pci express switch port */
uint8_t port;
+
+ /*
+ * This field declares Streamlined Virtual Channel (SVC) capability.
+ * Per PCIe 6.4 specification section 7.9.29, a pcie port supports
+ * upto 8 SVCs, in that SVC0 is a default one, SVC3 is for UIO traffic
+ * and SVC 4 is shared by both UIO and non-UIO traffic.
What actually goes in there? Is this literally the SVC capability content?
Yes, this is the SVC capability of the port and is a bitmap which will be
populated based on the emulation parameters of the port.
+ */
+ uint32_t svc;
};
+#define UIO_MANDATORY_SVC 3
+#define UIO_OPTIONAL_SVC 4
+
+static inline bool get_uio_mandatory_svc(PCIEPort *port)
+{
+ return (port->svc >> UIO_MANDATORY_SVC) & 1;
Could just define the field mask given I don't think you ever care about them
being the numeric values themselves. If you need the value defines later, then
fair enough.
If you do switch to defining fields.
return port->svc & UIO_MANDATORY_SVC;
and rely on boolean cast from non 0 to be true.
Also, do we want to route those two defines through the kernel
uapi/linux/pci_regs.h
and then just make use of them in QEMU?
Actually these are not registers, just a macro definition used to denote SVC3
and SVC4. These definitions are used to enable/verify the bitmap declared
above (uint32_t svc) and I guess routing from linux/pci_regs.h is not
required.
I kind of assume you have some kernel patches as well as this qemu support so
it would form part of that?
Yeah, we are peparing kernel patches and will be sent out shortly.
