RE: In device tree, can't understand 'ranges' property of PCIe root complex node

2023-02-13 Thread Chan Kim


Hello all,

I forgot that I asked this question here and I'll write what I have found
later.

I found in 'PCI bus bindings to : IEEE Std 1275-1994 standard for Boot
firmware' document, this 'range' property is for pci-to-pci bridge (and RC
contains bridge property I understand). So if an address range is behind
that bridge, that should be included in the 'ranges' property.

And '6. Probing PCI-to-PCI bridges' of the document says (after setting the
bridge parameters during the scan) "After setting the Memory Base, Memory
Limit, I/O Base and I/O Limit registers, create a "ranges" property that
represents the Memory and I/O mappings that have been established." . So it
looks like this parameter is set by the bus scanning entity like bootloader
or kernel.

So BAR is setting the PCIe address range for each device/function, and
'ranges' is for setting address ranges covering all the devices behind the
RC. I think the ranges can be merged or combined for some devices and it
provides also the translation relation(between PCIe address and host CPU
address). And I haven't check in the linux source but this 'ranges' property
should be set in the address translation unit inside the PCIe RC core. (For
example, in Synopsys PCIe core, there is iATU-internal address translation
unit- for which we can set address translation entries for some ranges.).
and I also guess when we do ioremap for a PCIe BAR address, it will consider
this address translation for that address too.

But still, I'm curious what happens in the existing 'ranges' property in the
device tree before the bus scanning. Does the bootloader/kernel respect the
value always (and allocates address within that ranges when allocating
BARs.)? or can it ignore and override the range assignment?

I would appreciate if someone could clear things up for me.

Thank you.
Chan Kim


>-Original Message-
>From: Chan Kim 
>Sent: Monday, February 6, 2023 9:07 PM
>To: kernelnewbies@kernelnewbies.org
>Subject: In device tree, can't understand 'ranges' property of PCIe root
>complex node
>
>Hello all,
>
>For example in linux-5.15.68's arch/arm64/boot/dts/ti/k3-am64-main.dtsi,
>
>&cbass_main {
>
>... skip ...
>
>pcie0_rc: pcie@f102000 {
>compatible = "ti,am64-pcie-host", "ti,j721e-pcie-host";
>reg = <0x00 0x0f102000 0x00 0x1000>,
>  <0x00 0x0f10 0x00 0x400>,
>  <0x00 0x0d00 0x00 0x0080>,
>  <0x00 0x6800 0x00 0x1000>;
>
>reg-names = "intd_cfg", "user_cfg", "reg", "cfg";
>  ... skip ...
>
>#address-cells = <3>;
>#size-cells = <2>;
>
>   ...skip ...
>
>msi-map = <0x0 &gic_its 0x0 0x1>;
>ranges = <0x0100 0x00 0x68001000  0x00 0x68001000  0x00
>0x001>,
> <0x0200 0x00 0x68011000  0x00 0x68011000  0x00
>0x7fef000>;
>dma-ranges = <0x0200 0x0 0x0 0x0 0x0 0x0010 0x0>;
>};
>};
>
>the 'ranges' property says
>- IO space starting at address 0x68001000 with size 64KiB is mapped to the
>parent bus address 0x68001000.
>- a 32 bit memory address space starting with address 0x68011000 and size
>0x7fef000 is mapped to parent bus address 0x68011000.
>
>The device tree document says these addresses are all physical.
>What I can't understand is :
>
>I know the BIOS will set the BAR addresses during the enumeration process.
>This is allocating the endpoint's function to a certain PCIe bus address
and
>I guess setting BAR can be done without this 'ranges' information(it will
>assign free address range for that device according to the device's need).
>By the time linux kernel later reads this 'ranges' property, the BIOS (or
>bootloader) has already assigned different PCIe address to that device.
>Then, how is this 'ranges' property used by the kernel?
>
>Thank you.
>
>Chan Kim
>
>
>
>
>
>___
>Kernelnewbies mailing list
>Kernelnewbies@kernelnewbies.org
>https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies





___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Calculating private and shared memory for processes

2023-02-13 Thread Jeffrey Walton
On Fri, Feb 10, 2023 at 5:43 PM Rahul Gore (Nokia)  wrote:
>
> I’m trying to find private and shared memory usage of each process in Linux. 
> ...

Application should _not_ share memory across processes. That's a
security vulnerability. One app could corrupt memory, and cause
unpredictable results in another process.

You can check for processes which share memory by looking for the
GNU_SHARED section attribute in a [on-disk] program. There should be
no shared sections.

Tobias Klein's checksec may show programs which have GNU_SHARED . If
checksec does not check for it, then `readelf -l  | grep
GNU_SHARED` should reveal it.

I'm guessing private memory usage is an easier problem. Profiling
tools probably provide it. Tools like 'perf mem' and Valgrind provide
the information.

Jeff

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Calculating private and shared memory for processes

2023-02-13 Thread Rahul Gore (Nokia)
Hello,

Just wanted to follow up on this question. Please let me know if I'm missing 
anything basic that I need to do to solve this problem.

Regards,
Rahul

From: Rahul Gore (Nokia)
Sent: Friday, February 10, 2023 2:43 PM
To: kernelnewbies@kernelnewbies.org
Subject: Calculating private and shared memory for processes

Hi,

I'm trying to find private and shared memory usage of each process in Linux. 
One answer on Stack Overflow suggested using 'smem' utility (it reads 
/proc//smap). However, the sum of all PSS values in 'smem' output is not 
equal to Used value of the 'free' utility (it reads /proc/meminfo).

CLI output:

$ sudo smem -t | tail -n 5
2950301 1002 gfstandalone_1_0 --test hw/0  1427244  1435899  1453060
2950368 1002 gfstandalone_1_1 --test hw/0  1432172  1440818  1457588
3012185 rgorejava -classpath /home/rgore0  2159256  2159348  2163268
---
  537 23 702168 2474 26865451 62093364
$ free -w
   totalusedfree  shared buffers   
cache   available
Mem:6562503626415500  511020  351372 1541640
3715687638119868
Swap:2097148  726148 1371000


So, I doubt the accuracy of the values in /proc//smap. Is there a more 
reliable alternative?

Regards,
Rahul
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies