[Skiboot] [ppc/pnv9] clarification on the dtb

[Amol]

On 16/03/2022, Frederic Barrat <fbarrat at linux.ibm.com> wrote:
>
>
> On 16/03/2022 17:20, Amol wrote:
>> Hello,
>>
>> Below is a part of the dtb file as passed on by the skiboot firmware to a
>> ppc64 pnv9 VM.
>>
>> The skiboot version is the one shipped with qemu's version
>> "QEMU emulator version 6.2.50 (v6.2.0-1976-g6629bf78aa)"
>>
>> / {
>> 	....
>> 	compatible = "qemu,powernv9\0ibm,powernv";
>> 	model = "IBM PowerNV (emulated by qemu)";
>> 	pciex at 600c3c0000000 {
>> 		compatible = "ibm,power9-pciex\0ibm,ioda3-phb";
>> 		device_type = "pciex";
>> 		....
>> 		#address-cells = <0x03>;
>> 		#size-cells = <0x02>;
>> 		#interrupt-cells = <0x01>;
>> 		interrupt-parent = <0x804e>;
>> 		ranges = <0x2000000 0x00 0x80000000 0x600c0 0x00 0x00
>> 			0x7fff0000>;
>> 		....                 /*  <-------- no interrupt-map HERE */
>> 		pci at 0 {
>> 			interrupts = <0x01>; /* <------------------ HERE */
>> 			#address-cells = <0x03>;
>> 			#size-cells = <0x02>;
>> 			#interrupt-cells = <0x01>;
>> 			interrupt-map-mask = <0x00 0x00 0x00 0x07>;
>> 			interrupt-map =
>> <0x00 0x00 0x00 0x01 0x804e 0xfeff8 0x01
>>   0x00 0x00 0x00 0x02 0x804e 0xfeff9 0x01
>>   0x00 0x00 0x00 0x03 0x804e 0xfeffa 0x01
>>   0x00 0x00 0x00 0x04 0x804e 0xfeffb 0x01>;
>> 			ranges = <0x2000000 0x00 0x00 0x2000000 0x00 0x00
>> 				0xf0000000 0x00>;
>> 		};
>> 	};
>>
>> Of interest is the "interrupts = <0x01>;" property of the pci at 0 node. It
>> has
>> "interrupts = <0x01>" property, which refers to the PCI #INTA. But its
>> parent,
>> the ioda3 node, does not have the corresponding interrupt-map facility to
>> map the #INTA over to a descriptor understood/required by the interrupt
>> controller.
>>
>> I checked a dtb, linked at [2], seemingly captured from a hardware
>> machine,
>> and found no such violation at least among the pci nodes. In it, there is
>> a pci at 0 node with "interrupts = <0x01>", but it does have a parent,
>> another
>> pci at 0 node, which possesses the interrupt-map mapping required for
>> translation.
>>
>> I checked the qemu's raw DTB output and found that it does not contain
>> those
>> pci-related nodes - they are being added by skiboot.
>>
>> Is such a setup allowed under the dtb spec? The skiboot function which
>> seems to
>> add the nodes is pci_add_one_device_node or its peers.
>
>
> That is a bug from the powernv model of qemu. It reuses a "generic"
> root port device which already existed in qemu and that generic device
> declares it wants a LSI (Interrupt Pin Register (Offset 3Dh) in the
> config space). That's where the following entry is coming from:
>
>   		pci at 0 {
> 			interrupts = <0x01>; /* <-------- HERE

Thank you for the information.

qemu's phb4 rootport is a subclass of the rootport class rp, and
rp_realize (which the phb4 rp calls) sets the interrupt pin to #INTA.

>
> However skiboot doesn't add an interrupt-map property under
> "pciex at 600c3c0000000" to handle that LSI interrupt. Because, as you
> noticed, that doesn't make sense on real hardware.

Right. The dtb at [2] shows that all root ports are devoid of the
interrupts property.

>
> So you're correct, the device tree seen under qemu is wrong.
>
> Any specific reason why you're looking into it?

I was trying to understand how one can extract information out of the
dtb to then use it to program the PCI devices and to configure their
interrupts on the interrupt controller. As someone who isn't very
familiar with the dtb, I was confused, as this situation conflicted with the
general rules that are found to be followed when describing the
hardware layout in a dtb.

Thanks,
Amol

>
>    Fred
>
>
>
>
>> Thanks,
>> Amol
>>
>> [1] https://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
>> [2] https://people.freebsd.org/~jhibbits/p9_vga_out_devtree.txt
>> _______________________________________________
>> Skiboot mailing list
>> Skiboot at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/skiboot
>