Re: [PATCH pciutils v1] pciutils: add new readpci utility

[Jesse Brandeburg <jesse.brandeburg@intel.com>]

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!