On Mon, 25 Nov 2019 10:30:22 +0000
Alexandru Elisei <alexandru.elisei@xxxxxxx> wrote:
> The "bus-range" property encodes the first and last bus number. kvmtool
> uses bus 0 for PCI and bus 1 for MMIO.
Mmmh, but this DT setting is about (guest visible) PCI busses, not kvmtool busses, isn't it?
So for the PCI devices we *emulate* that's probably correct, since we don't have any PCI bridge functionality among them, but wouldn't forwarding a PCI device with a bridge require more than one bus? And the guest OS' enumeration code would try to create a new bus, but fails, because there is only one?
So I agree that the [0, 1] looks somewhat arbitrary, but shouldn't we set it to [0, 255] instead, to not limit things?
I think this setting should correspond to the PCIe config space size we provide, which should be: 4096 bytes * 8 fns * 32 devs * nr_busses (for PCIe).
At least that's my understanding of these things, please correct me if I am wrong.
Cheers,
Andre.
> Advertise only the PCI bus in
> the PCI DT node by setting "bus-range" to <0, 0>.
>
> Signed-off-by: Alexandru Elisei <alexandru.elisei@xxxxxxx>
> ---
> arm/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arm/pci.c b/arm/pci.c
> index 557cfa98938d..ed325fa4a811 100644
> --- a/arm/pci.c
> +++ b/arm/pci.c
> @@ -30,7 +30,7 @@ void pci__generate_fdt_nodes(void *fdt)
> struct of_interrupt_map_entry irq_map[OF_PCI_IRQ_MAP_MAX];
> unsigned nentries = 0;
> /* Bus range */
> - u32 bus_range[] = { cpu_to_fdt32(0), cpu_to_fdt32(1), };
> + u32 bus_range[] = { cpu_to_fdt32(0), cpu_to_fdt32(0), };
> /* Configuration Space */
> u64 cfg_reg_prop[] = { cpu_to_fdt64(KVM_PCI_CFG_AREA),
> cpu_to_fdt64(ARM_PCI_CFG_SIZE), };
