On 10/11/2022 9:49 AM, Bjorn Helgaas wrote:
I like this idea. I often use rdwrmem, which is more general-purpose,
but it's a bit of a hassle that it's not commonly installed like
pciutils is, and you have to manually come up with the physical
address of a BAR.
I think that's a lot of the advantage of this tool. And yes, there are a
lot of other versions of this program around that just read/write
/dev/mem. Having it come with the pciutils makes the most sense to me,
which is why I'm here.
The names:
"setpci" -- read and write PCI config space
"readpci" -- read and write PCI MMIO BARs
are slightly confusing since both support reads *and* writes, and
there's no clear config space vs BAR connection in the names.
Yeah, naming is super hard. I chose the *pci name to just keep it
consistent with the tools in this package, but if Martin or you has some
other suggestions, we can rabbit down that hole. I'm not super opposed
to something like:
"mmio_write_pci"
or even
"mmio_pci"
Would it make any sense to integrate this into setpci, e.g., by
adding an address format for BAR MMIO offsets?
I hadn't thought of that, but it's not a horrible idea. My feeling in
general is that I like to differentiate the tools to having "one job"
sort of unix/posix style, and since this one reads/writes mmio, offset
from the BAR, I prefer that setpci keep the job of reading/writing PCI
registers, and this new thing does mmio.
basic usage to read a register:
$ sudo ./readpci -s 17:0.0 -a 0xb8000
17:00.0 (8086:1592) - Device 8086:1592
0xb8000 == 0x1
Possibly annotate with the BAR # and the complete physical address (to
correlate with lspci or dmesg output, especially when debugging via
email)? Maybe also useful with reading MSI-X BAR. Looks like maybe
it already does some of this with "v".
I think your point is reasonable, here is the -v output currently:
$ sudo ./readpci -s 17:0.0 -a 0xb8000 -v
17:00.0 (8086:1592) - Device 8086:1592
BAR0: len 0x02000000
0xb8000 == 0x1
Maybe I should print the BAR0 address as well, basically yielding the
bits of math that were used to find the final offset and printing that
too in verbose mode?
Maybe something like (proposal)
$ sudo ./readpci -s 17:0.0 -a 0xb8000 -v
17:00.0 (8086:1592) - Device 8086:1592
BAR0: Memory at 387ffa000000 (64-bit, prefetchable) [size=32M]
Final address: 387ffa0b8000
0xb8000 == 0x00000001
<the BAR0 string is like the one from lspci -vvv>
Possibly fill out the value to indicate the access width, e.g.,
0x00000001 in this case?
yes, good point.
Currently the utility only allows reading or writing one 32 bit address at
a time. The utility must be run as root.
Does this mean the *address* is limited to 32 bits, or the access size
is 32 bits?
Yeah, I should clarify that, it's the size of the target register, not
the address, however, I don't have any devices with > 4GB of registers
to try it out on to see if larger addresses will work.
+++ b/readpci.man
+Access to read and write registers in PCI configuration space is restricted to root,
IIUC, readpci is for MMIO, not config space. But I guess readpci
still needs data from config space to figure out *where* to read? But
I assume that would normally come from sysfs, not config space
directly, so we can account for _TRA offsets. I assume that info is
sysfs is also root-only, so it amounts to the same thing. And
/dev/mem itself is also root-only.
I think this is a copy/paste error, so will fix. It was meant to be
saying Access to read and write registers via /dev/mem is restricted to
root.
I guess I would say either just "readpci can only be used by root" or
list the items actually required (sysfs config info and /dev/mem) in
case access to them requires different CAP_SYS_* things.
In this case the app actually checks it's being run by UID 0, since
we'll get all sorts of chained failures if you run it as a regular user.
But simplifying the text as you suggested is best.
+So,
+.I readpci
+isn't available to normal users.
+.B -b [<value>]
+Optional parameter, defaults to 0 if not specified. BAR number to access if
+other than BAR0.
Maybe move the main point ("BAR number") first, mention the "optional"
part later?
OK, will fix
+on any bus, "0.3" selects third function of device 0 on all buses and ".4" shows only
+the fourth function of each device.
Isn't "0.3" the *fourth* function? 0.0, 0.1, 0.2, 0.3? Maybe reword
to avoid the question of whether we start with "zeroth" or "first",
e.g., "0.3 selects function 3 of device 0 on all buses"?
Good point, will fix.
+There might be some, but none known at this time. If you find one please
+let the list know.
Does this man page say what "the list" refers to?
I'll expand it!
Thanks for the review!
