| 449dca6a | 23-Oct-2024 |
Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> |
pcie: enable Extended tag field support
>From what I read PCI has 32 transactions, PCI Express devices can handle
256 with Extended tag enabled (spec mentions also larger values but I
lack PCIe know
pcie: enable Extended tag field support
>From what I read PCI has 32 transactions, PCI Express devices can handle
256 with Extended tag enabled (spec mentions also larger values but I
lack PCIe knowledge).
QEMU leaves 'Extended tag field' with 0 as value:
Capabilities: [e0] Express (v1) Root Complex Integrated Endpoint, IntMsgNum 0
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+ FLReset- TEE-IO-
SBSA ACS has test 824 which checks for PCIe device capabilities. BSA
specification [1] (SBSA is on top of BSA) in section F.3.2 lists
expected values for Device Capabilities Register:
Device Capabilities Register Requirement
Role based error reporting RCEC and RCiEP: Hardwired to 1
Endpoint L0s acceptable latency RCEC and RCiEP: Hardwired to 0
L1 acceptable latency RCEC and RCiEP: Hardwired to 0
Captured slot power limit scale RCEC and RCiEP: Hardwired to 0
Captured slot power limit value RCEC and RCiEP: Hardwired to 0
Max payload size value must be compliant with PCIe spec
Phantom functions RCEC and RCiEP: Recommendation is to
hardwire this bit to 0.
Extended tag field Hardwired to 1
1. https://developer.arm.com/documentation/den0094/c/
This change enables Extended tag field. All versioned platforms should
have it disabled for older versions (tested with Arm/virt).
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Message-Id: <20241023113820.486017-1-marcin.juszkiewicz@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| 55fa4be6 | 30-Oct-2024 |
Gao Shiyuan <gaoshiyuan@baidu.com> |
virtio-pci: fix memory_region_find for VirtIOPCIRegion's MR
As shown below, if a virtio PCI device is attached under a pci-bridge, the MR
of VirtIOPCIRegion does not belong to any address space. So
virtio-pci: fix memory_region_find for VirtIOPCIRegion's MR
As shown below, if a virtio PCI device is attached under a pci-bridge, the MR
of VirtIOPCIRegion does not belong to any address space. So memory_region_find
cannot be used to search for this MR.
Introduce the virtio-pci and pci_bridge address spaces to solve this problem.
Before:
memory-region: pci_bridge_pci
0000000000000000-ffffffffffffffff (prio 0, i/o): pci_bridge_pci
00000000fe840000-00000000fe840fff (prio 1, i/o): virtio-net-pci-msix
00000000fe840000-00000000fe84003f (prio 0, i/o): msix-table
00000000fe840800-00000000fe840807 (prio 0, i/o): msix-pba
0000380000000000-0000380000003fff (prio 1, i/o): virtio-pci
0000380000000000-0000380000000fff (prio 0, i/o): virtio-pci-common-virtio-net
0000380000001000-0000380000001fff (prio 0, i/o): virtio-pci-isr-virtio-net
0000380000002000-0000380000002fff (prio 0, i/o): virtio-pci-device-virtio-net
0000380000003000-0000380000003fff (prio 0, i/o): virtio-pci-notify-virtio-net
After:
address-space: virtio-pci-cfg-mem-as
0000380000000000-0000380000003fff (prio 1, i/o): virtio-pci
0000380000000000-0000380000000fff (prio 0, i/o): virtio-pci-common-virtio-net
0000380000001000-0000380000001fff (prio 0, i/o): virtio-pci-isr-virtio-net
0000380000002000-0000380000002fff (prio 0, i/o): virtio-pci-device-virtio-net
0000380000003000-0000380000003fff (prio 0, i/o): virtio-pci-notify-virtio-net
address-space: pci_bridge_pci_mem
0000000000000000-ffffffffffffffff (prio 0, i/o): pci_bridge_pci
00000000fe840000-00000000fe840fff (prio 1, i/o): virtio-net-pci-msix
00000000fe840000-00000000fe84003f (prio 0, i/o): msix-table
00000000fe840800-00000000fe840807 (prio 0, i/o): msix-pba
0000380000000000-0000380000003fff (prio 1, i/o): virtio-pci
0000380000000000-0000380000000fff (prio 0, i/o): virtio-pci-common-virtio-net
0000380000001000-0000380000001fff (prio 0, i/o): virtio-pci-isr-virtio-net
0000380000002000-0000380000002fff (prio 0, i/o): virtio-pci-device-virtio-net
0000380000003000-0000380000003fff (prio 0, i/o): virtio-pci-notify-virtio-net
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2576
Fixes: ffa8a3e3b2e6 ("virtio-pci: Add lookup subregion of VirtIOPCIRegion MR")
Co-developed-by: Zuo Boqun <zuoboqun@baidu.com>
Signed-off-by: Zuo Boqun <zuoboqun@baidu.com>
Co-developed-by: Wang Liang <wangliang44@baidu.com>
Signed-off-by: Wang Liang <wangliang44@baidu.com>
Signed-off-by: Gao Shiyuan <gaoshiyuan@baidu.com>
Message-Id: <20241030131324.34144-1-gaoshiyuan@baidu.com>
Tested-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| ea3f0ebc | 16-Sep-2024 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
hw/pcie: Provide a utility function for control of EP / SW USP link
Whilst similar to existing PCIESlot link configuration a few registers
need to be set differently so that the downstream device pr
hw/pcie: Provide a utility function for control of EP / SW USP link
Whilst similar to existing PCIESlot link configuration a few registers
need to be set differently so that the downstream device presents
a 'configured' state that is then used to 'train' the upstream port
on the link. Basically that means setting the status register to
reflect it succeeding in training up to target settings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20240916173518.1843023-5-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| aa37616f | 01-Aug-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/pci/pci-hmp-cmds: Avoid displaying bogus size in 'info pci'
When BAR aren't mapped, we get:
(qemu) info pci
Bus 0, device 0, function 0:
Host bridge: PCI device dead:beef
hw/pci/pci-hmp-cmds: Avoid displaying bogus size in 'info pci'
When BAR aren't mapped, we get:
(qemu) info pci
Bus 0, device 0, function 0:
Host bridge: PCI device dead:beef
...
BAR4: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
BAR5: I/O at 0xffffffffffffffff [0x0ffe].
Check the BAR is mapped comparing its address to PCI_BAR_UNMAPPED
which is what the PCI layer uses for unmapped BARs.
See pci_bar_address and pci_update_mappings implementations and
in "hw/pci/pci.h":
typedef struct PCIIORegion {
pcibus_t addr; /* current PCI mapping address. -1 means not mapped */
#define PCI_BAR_UNMAPPED (~(pcibus_t)0)
...
This improves the logging, not displaying bogus sizes:
(qemu) info pci
Bus 0, device 0, function 0:
Host bridge: PCI device dead:beef
...
BAR4: 32 bit memory (not mapped)
BAR5: I/O (not mapped)
Remove trailing dot which is not used in other commands format.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20240801131449.51328-1-philmd@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| e228d62b | 07-Jul-2024 |
Dongli Zhang <dongli.zhang@oracle.com> |
pci: don't skip function 0 occupancy verification for devfn auto assign
When the devfn is already assigned in the command line, the
do_pci_register_device() may verify if the function 0 is already o
pci: don't skip function 0 occupancy verification for devfn auto assign
When the devfn is already assigned in the command line, the
do_pci_register_device() may verify if the function 0 is already occupied.
However, when devfn < 0, the verification is skipped because it is part of
the last "else if".
For instance, suppose there is already a device at addr=00.00 of a port.
-device pcie-root-port,bus=pcie.0,chassis=115,id=port01,addr=0e.00 \
-device virtio-net-pci,bus=port01,id=vnet01,addr=00.00 \
When 'addr' is specified for the 2nd device, the hotplug is denied.
(qemu) device_add virtio-net-pci,bus=port01,id=vnet02,addr=01.00
Error: PCI: slot 0 function 0 already occupied by virtio-net-pci, new func virtio-net-pci cannot be exposed to guest.
When 'addr' is automatically assigned, the hotplug is not denied. This is
because the verification is skipped.
(qemu) device_add virtio-net-pci,bus=port01,id=vnet02
warning: PCI: slot 1 is not valid for virtio-net-pci, parent device only allows plugging into slot 0.
Fix the issue by moving the verification into an independent 'if'
statement.
Fixes: 3f1e1478db2d ("enable multi-function hot-add")
Reported-by: Aswin Unnikrishnan <aswin.u.unnikrishnan@oracle.com>
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Message-Id: <20240708041056.54504-1-dongli.zhang@oracle.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| 122173a5 | 15-Jul-2024 |
Akihiko Odaki <akihiko.odaki@daynix.com> |
pcie_sriov: Allow user to create SR-IOV device
A user can create a SR-IOV device by specifying the PF with the
sriov-pf property of the VFs. The VFs must be added before the PF.
A user-creatable VF
pcie_sriov: Allow user to create SR-IOV device
A user can create a SR-IOV device by specifying the PF with the
sriov-pf property of the VFs. The VFs must be added before the PF.
A user-creatable VF must have PCIDeviceClass::sriov_vf_user_creatable
set. Such a VF cannot refer to the PF because it is created before the
PF.
A PF that user-creatable VFs can be attached calls
pcie_sriov_pf_init_from_user_created_vfs() during realization and
pcie_sriov_pf_exit() when exiting.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20240715-sriov-v5-5-3f5539093ffc@daynix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| 47cc753e | 15-Jul-2024 |
Akihiko Odaki <akihiko.odaki@daynix.com> |
pcie_sriov: Check PCI Express for SR-IOV PF
SR-IOV requires PCI Express.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20240715-sriov-v5-4-3f5539093ffc@daynix.com>
Reviewed-b
pcie_sriov: Check PCI Express for SR-IOV PF
SR-IOV requires PCI Express.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20240715-sriov-v5-4-3f5539093ffc@daynix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|
| 78f9d7fd | 15-Jul-2024 |
Akihiko Odaki <akihiko.odaki@daynix.com> |
pcie_sriov: Ensure PF and VF are mutually exclusive
A device cannot be a SR-IOV PF and a VF at the same time.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20240715-sriov-v5-
pcie_sriov: Ensure PF and VF are mutually exclusive
A device cannot be a SR-IOV PF and a VF at the same time.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-Id: <20240715-sriov-v5-3-3f5539093ffc@daynix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
show more ...
|