kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandru Elisei <alexandru.elisei@arm.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: kvm@vger.kernel.org, will@kernel.org,
	julien.thierry.kdev@gmail.com, sami.mujawar@arm.com,
	lorenzo.pieralisi@arm.com
Subject: Re: [PATCH kvmtool 05/16] arm: pci.c: Advertise only PCI bus 0 in the DT
Date: Wed, 15 Jan 2020 14:49:08 +0000	[thread overview]
Message-ID: <63dbad4e-a6c8-f609-53d0-e3df018feb08@arm.com> (raw)
In-Reply-To: <20191128174315.26208e51@donnerap.cambridge.arm.com>

Hi,

On 11/28/19 5:43 PM, Andre Przywara wrote:
> On Mon, 25 Nov 2019 10:30:22 +0000
> Alexandru Elisei <alexandru.elisei@arm.com> 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?

You are correct, this setting is about guest visible PCI busses, not kvmtool
buses, I got the two confused.

> 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).

kvmtool emulates a single bus, bus 0. Whenever the PCI code searches for a device,
it searches using the device number, not a tuple (bus_number, device_number) (take
a look at pci__config_{rd,wr}). Also, in pci_device_exists, it compares the bus
number and function number against 0, the default values from
pci_config_address_bits. On the other hand, kvmtool doesn't emulate any bridges,
so after probing bus 0, Linux won't try to probe any other buses. So regardless of
the bus-range property, Linux will only probe bus 0.

From a correctness point of view, I think <0,0> is the right value here as it
matches what kvmtool emulates. What do you think?

Thanks,
Alex
>
> 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@arm.com>
>> ---
>>  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), };

  reply	other threads:[~2020-01-15 14:49 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 10:30 [PATCH kvmtool 00/16] Add writable BARs and PCIE 1.1 support Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 01/16] Makefile: Use correct objcopy binary when cross-compiling for x86_64 Alexandru Elisei
2019-11-27 18:23   ` Andre Przywara
2019-11-25 10:30 ` [PATCH kvmtool 02/16] pci: Fix BAR resource sizing arbitration Alexandru Elisei
2019-11-27 18:24   ` Andre Przywara
2019-11-28  9:37     ` Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 03/16] Remove pci-shmem device Alexandru Elisei
2019-11-27 18:24   ` Andre Przywara
2019-11-25 10:30 ` [PATCH kvmtool 04/16] Check that a PCI device's memory size is power of two Alexandru Elisei
2019-11-27 18:25   ` Andre Przywara
2020-01-15 12:43     ` Alexandru Elisei
2020-01-15 14:07       ` Andre Przywara
2020-01-15 15:00         ` Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 05/16] arm: pci.c: Advertise only PCI bus 0 in the DT Alexandru Elisei
2019-11-28 17:43   ` Andre Przywara
2020-01-15 14:49     ` Alexandru Elisei [this message]
2019-11-25 10:30 ` [PATCH kvmtool 06/16] ioport: pci: Move port allocations to PCI devices Alexandru Elisei
2020-01-28 18:25   ` Andre Przywara
2020-01-29 10:07     ` Alexandru Elisei
2020-01-29 10:29       ` Andre Przywara
2019-11-25 10:30 ` [PATCH kvmtool 07/16] pci: Fix ioport allocation size Alexandru Elisei
2020-01-28 18:26   ` Andre Przywara
2020-01-29 11:11     ` Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 08/16] arm/pci: Fix PCI IO region Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 09/16] arm/pci: Do not use first PCI IO space bytes for devices Alexandru Elisei
2019-12-02 12:15   ` Lorenzo Pieralisi
2020-01-15 15:08     ` Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 10/16] virtio/pci: Make memory and IO BARs independent Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 11/16] virtio/pci: Ignore MMIO and I/O accesses when they are disabled Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 12/16] Use independent read/write locks for ioport and mmio Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 13/16] vfio: Add support for BAR configuration Alexandru Elisei
2019-11-29 17:05   ` Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 14/16] virtio/pci: " Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 15/16] arm/fdt: Remove 'linux,pci-probe-only' property Alexandru Elisei
2019-11-25 10:30 ` [PATCH kvmtool 16/16] Add PCI Express 1.1 support Alexandru Elisei
2019-11-28 17:41 ` [PATCH kvmtool 00/16] Add writable BARs and PCIE " Lorenzo Pieralisi
2020-01-15 15:10   ` Alexandru Elisei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=63dbad4e-a6c8-f609-53d0-e3df018feb08@arm.com \
    --to=alexandru.elisei@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=sami.mujawar@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).