| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
MFC after: 2 weeks
(cherry picked from commit 5d9e5a7edfb5a2256be1c6433aaef32433cdd14e)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Re-implement pcib interface to use standard pci bus driver on top of
vmd(4) instead of custom one.
- Re-implement memory/bus resource allocation to properly handle even
complicated configurations.
- Re-implement interrupt handling to evenly distribute children's MSI/
MSI-X interrupts between available vmd(4) MSI-X vectors and setup them
to be handled by standard OS mechanisms with minimal overhead, except
sharing when unavoidable.
Successfully tested on Dell XPS 13 laptop with Core i7-1185G7 CPU (VMD
device ID 0x9a0b) and single NVMe SSD, dual-booting with Windows 10.
Successfully tested on Supermicro X11DPI-NT motherboard with Xeon(R)
Gold 6242R CPUs (VMD device ID 0x201d), simultaneously handling NVMe
SSD on one PCIe port and PLX bridge with 3 NVMe and 1 AHCI SSDs on
another. Handles SSD hot-plug (except Optane 905p for some reason,
which are not detected until manual bus rescan) and enabled IOMMU
(directly connected SSDs work, but ones connected to the PLX fail
without errors from IOMMU).
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Differential revision: https://reviews.freebsd.org/D31762
(cherry picked from commit 7af4475a6e31202a865b1dd3727018659b44470f)
|
| |
|
|
|
|
|
| |
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D31210
(cherry picked from commit 76fffd0a865374e1e09d8f61f36bfbda918da5c7)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes a kernel panic when probing for vmd_bus on Intel TigerLake on
14-CURRENT. Apparently, vmd_bus is a type of PCI bus, but was registered
as a separate device class.
PR: 256915
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D31071
(cherry picked from commit ad1f608fb2f529baf028384bbe7e8fbbff5cbe23)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for some more Intel VMD controllers. Some of the
newer controller have a sparce bus space that can be figured
out by probing the HW. This gives the starting bus number.
When reading the PCI config. space behind the VMD controller,
the offset of the starting bus needs to be subtracted from
the bus being read.
Fixed a bug in which in which not all of the devices
directly attached to the VMD controller would be probed.
On my initial test HW, a switch was found at bus 0, slot 0
and function 0. All of the NVME drives were behind that
switch. Now scan for all slots and functions attached to
bus 0. If a something was found then run attach after the
scan. On detach also go through all slots and functions
on bus 0.
Tested with device ID's: 0x201d & 0x9a0b
Tested by: nc@
MFC: 5c689e21361
PR: 252253
(cherry picked from commit 0c852bb9b9282b30fd047ac1de398358f33777f4)
|
| |
|
|
|
|
|
|
| |
- Free the resource container by calling rman_fini().[1]
- Call device_delete_child() if device_probe_and_attach() fails.
Reported by: nc [1]
MFC after: 2 weeks
|
| |
|
|
| |
Notes:
svn path=/head/; revision=365137
|
|
|
starting at the max. domain, and then work down. Then existing FreeBSD
drivers will attach. Interrupt routing from the VMD MSI-X to the NVME
drive is not well known, so any interrupt is sent to all children that
register.
VROC used Intel meta data so graid(8) works with it. However, graid(8)
supports RAID 0,1,10 for read and write. I have some early code to
support writes with RAID 5. Note that RAID 5 can have life issues
with SSDs since it can cause write amplification from updating the parity
data.
Hot plug support needs a change to skip the following check to work:
if (pcib_request_feature(dev, PCI_FEATURE_HP) != 0) {
in sys/dev/pci/pci_pci.c.
Looked at by: imp, rpokala, bcr
Differential Revision: https://reviews.freebsd.org/D21383
Notes:
svn path=/head/; revision=353380
|
