| 7c83a1e3 | 16-Jun-2021 |
David Marchand <[email protected]> |
bus/pci: fix leak for unbound devices
For devices not bound to any Linux kernel module, we leak a pci object
since it is never added to the PCI bus device list.
Fixes: c79a1c67465d ("bus/pci: optim
bus/pci: fix leak for unbound devices
For devices not bound to any Linux kernel module, we leak a pci object
since it is never added to the PCI bus device list.
Fixes: c79a1c67465d ("bus/pci: optimize bus scan")
Cc: [email protected]
Reported-by: Owen Hilyard <[email protected]>
Signed-off-by: David Marchand <[email protected]>
show more ...
|
| fc5bffb8 | 23-Jun-2021 |
David Christensen <[email protected]> |
bus/pci: support IOVA as VA in PowerVM LPARs
Add IOMMU detection logic for PowerVM LPARs.
PowerNV $ cat /proc/cpuinfo
...
timebase : 512000000
platform : PowerNV
model : 8335-GTW
Po
bus/pci: support IOVA as VA in PowerVM LPARs
Add IOMMU detection logic for PowerVM LPARs.
PowerNV $ cat /proc/cpuinfo
...
timebase : 512000000
platform : PowerNV
model : 8335-GTW
PowerVM LPAR $ cat /proc/cpuinfo
...
timebase : 512000000
platform : pSeries
model : IBM,9009-22A
machine : CHRP IBM,9009-22A
MMU : Hash
PowerNV KVM Guest $ cat /proc/cpuinfo
...
timebase : 512000000
platform : pSeries
model : IBM pSeries (emulated by qemu)
machine : CHRP IBM pSeries (emulated by qemu)
MMU : Radix
Signed-off-by: David Christensen <[email protected]>
Reviewed-by: Thinh Tran <[email protected]>
show more ...
|
| df58e45e | 10-Mar-2021 |
Huawei Xie <[email protected]> |
bus/pci: support MMIO for ioport
With I/O BAR, we get PIO (port-mapped I/O) address.
With MMIO (memory-mapped I/O) BAR, we get mapped virtual address.
We distinguish PIO and MMIO by their address ra
bus/pci: support MMIO for ioport
With I/O BAR, we get PIO (port-mapped I/O) address.
With MMIO (memory-mapped I/O) BAR, we get mapped virtual address.
We distinguish PIO and MMIO by their address range like how kernel does,
i.e, address below 64K is PIO.
ioread/write8/16/32 is provided to access PIO/MMIO.
By the way, for virtio on arch other than x86, BAR flag indicates PIO
but is mapped.
Signed-off-by: Huawei Xie <[email protected]>
Reviewed-by: Maxime Coquelin <[email protected]>
Tested-by: Yinan Wang <[email protected]>
show more ...
|
| 2a089d2d | 11-Sep-2020 |
Yunjian Wang <[email protected]> |
bus/pci: fix leak on VFIO mapping error
Currently, only the 'vfio_dev_fd' is closed in failure path, so
some resources are not released(such as 'vfio_group_fd'). The
rte_vfio_release_device() should
bus/pci: fix leak on VFIO mapping error
Currently, only the 'vfio_dev_fd' is closed in failure path, so
some resources are not released(such as 'vfio_group_fd'). The
rte_vfio_release_device() should be used to avoid this problem.
Fixes: 33604c31354a ("vfio: refactor PCI BAR mapping")
Cc: [email protected]
Signed-off-by: Yunjian Wang <[email protected]>
Reviewed-by: Anatoly Burakov <[email protected]>
show more ...
|
| e1ece609 | 17-Sep-2020 |
David Marchand <[email protected]> |
pci: move resource mapping to the PCI bus
As reported during 20.08 work for Windows, the pci_map_resource API was
built with the assumption that its flags would be passed to mmap().
This introduced
pci: move resource mapping to the PCI bus
As reported during 20.08 work for Windows, the pci_map_resource API was
built with the assumption that its flags would be passed to mmap().
This introduced a regression when adding the rte_mem_map API as reported
in the workaround commit 9d2b24593724 ("pci: keep API compatibility with
mmap values").
This API was only used in the PCI bus code, so move it there.
There is no code change happening during the move.
The only change is in the pci_map_resource description where the
additional flags are now documented as rte_mem_map API flags:
- * The additional flags for the mapping range.
+ * The additional rte_mem_map() flags for the mapping range.
Signed-off-by: David Marchand <[email protected]>
Acked-by: Andrew Rybchenko <[email protected]>
Acked-by: Ray Kinsella <[email protected]>
show more ...
|