Child devices handling I/O port resources (such as PCI-e bridges)
should map those to a memory resource and pass up a request for the
translated memory resource.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Booting a RISC-V image under qemu with a virtio-rng-pci device seems to have exercised this as it has a pci_host_generic as a child of a simplebus:
pcib0: <Generic PCI host controller> mem 0x30000000-0x3fffffff on simplebus1
pcib0: parsing FDT for ECAM0:
pcib0: Bus is cache-coherent
pcib0: PCI addr: 0x0, CPU addr: 0x3000000, Size: 0x10000, Type: I/O port
pcib0: PCI addr: 0x40000000, CPU addr: 0x40000000, Size: 0x40000000, Type: memory
pcib0: PCI addr: 0x400000000, CPU addr: 0x400000000, Size: 0x400000000, Type: memory
pci0: <PCI bus> on pcib0
pci0: domain=0, physical bus=0
found-> vendor=0x1b36, dev=0x0008, revid=0x00
domain=0, bus=0, slot=0, func=0
class=06-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found-> vendor=0x1af4, dev=0x1005, revid=0x00
domain=0, bus=0, slot=1, func=0
class=00-ff-00, hdrtype=0x00, mfdev=0
cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=0
MSI-X supports 2 messages in map 0x14
map[10]: type I/O Port, range 32, base 0, size 5, port disabled
map[14]: type Memory, range 32, base 0, size 12, memory disabled
map[20]: type Prefetchable Memory, range 64, base 0, size 14, memory disabled
virtio_pci0: <VirtIO PCI (legacy) Entropy adapter> irq 16 at device 1.0 on pci0
virtio_pci0: Lazy allocation of 0x20 bytes rid 0x10 type 4 at 0
virtio_pci0: Lazy allocation of 0x1000 bytes rid 0x14 type 3 at 0x40000000
`Some command output:
root@riscv64:~ # pciconf -lb
hostb0@pci0:0:0:0: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1b36 device=0x0008 subvendor=0x1af4 subdevice=0x1100
virtio_pci0@pci0:0:1:0: class=0x00ff00 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1005 subvendor=0x1af4 subdevice=0x0004
bar [10] = type I/O Port, range 32, base 0, size 32, enabled
bar [14] = type Memory, range 32, base 0x40000000, size 4096, enabled
bar [20] = type Prefetchable Memory, range 64, base 0, size 16384, enabled
root@riscv64:~ # devinfo -u
I/O memory addresses:
0x0-0xfffff (root0)
0x100000-0x100fff (riscv_syscon0)
0x101000-0x101fff (goldfish_rtc0)
0x102000-0x2ffffff (root0)
0x3000000-0x300ffff (pcib0)
0x3010000-0xbffffff (root0)
....
pcib0 I/O port window:
0x0-0x1f (virtio_pci0)
0x20-0xffff (root0)
....Comment Actions
Not with D44207 though, right? Even absent this change it should show up as I/O memory rather than I/O port, right? Or is that just showing that it's still an I/O port from pcib0 downwards; if so, that's not so relevant because that's not changed, what's relevant is how simplebus0 and above see it?
Comment Actions
This is after D44207 was merged, so it has it included. The point is that it only looks like an I/O port for pcib0 downwards. For simplebus0 it instead sees the SYS_RES_MEMORY resource allocated to pcib0 (0x3000000-0x300ffff (pcib0)) corresponding to the I/O window.
Comment Actions
That makes sense. The bit that doesn't to me is the portion of the range that's marked as owned by root0. Is that just a quirk of libdevinfo's DEVINFO_ROOT_DEVICE sentinel being 0, which is the same as NULL reports, i.e. for when there's no parent? Seems like that should instead be a different sentinel so NULL device fields can be handled correctly (that or each caller needs to check for NULL).
Comment Actions
Yeah, the (root0) are ranges that the rman manages (via rman_manage_region) but have no owner. There are some times when you will see a range marked (---) instead. But yeah, I think the (root0) case, especially for the pcib0 I/O window is a bug. root0 never owns any resources.
Comment Actions
Sigh, so yeah, the simple fix is DEVINFO_ROOT_DEVICE should probably be (uintptr_t)-1 or some such instead of NULL. Looks like libdevinfo is used by some ports like libinput and kwin. :( We could always just bump the SHLIB_MAJOR in main to fix this and not worry about fixing stable branches?