[PATCH v2] docs: Document reserved PCI addresses for QEMU

Michal Privoznik posted 1 patch 4 years ago
Test syntax-check failed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/065fe4414cc7c285769902ee7c9740bcfa1b0d93.1587491966.git.mprivozn@redhat.com
docs/pci-addresses.rst | 50 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
[PATCH v2] docs: Document reserved PCI addresses for QEMU
Posted by Michal Privoznik 4 years ago
>From time to time we are asked which PCI addresses are reserved
in QEMU. Let's document them in one place, it's easier than
reconstructing the list from the code each time.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---

diff to v1:
- All Laine's comment worked in, hopefully.

 docs/pci-addresses.rst | 50 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/docs/pci-addresses.rst b/docs/pci-addresses.rst
index 885d50517a..4f123c7eb9 100644
--- a/docs/pci-addresses.rst
+++ b/docs/pci-addresses.rst
@@ -235,3 +235,53 @@ guest OS rather than as ``0001:08:00.1``, which is the address of the
 device on the host.
 
 Of course, all the rules and behaviors described above still apply.
+
+
+Reserved addresses
+==================
+
+Due to some historical reasons hypervisors might expect some PCI
+devices to appear at certain addresses instead of 'random' ones.
+For QEMU this is machine type and guest architecture dependant.
+But to give you at least a gist here is list of reserved PCI
+addresses:
+
+For ``I440FX`` the following devices are hard coded into QEMU and can't be
+moved or eliminated:
+
+============  ======================
+0000:00:00.0  Host bridge
+0000:00:01.0  ISA bridge
+0000:00:01.1  primary IDE controller
+0000:00:01.2  PIIX3 USB controller
+0000:00:01.3  ACPI (power management) and SMBus controller
+============  ======================
+
+The following addresses will be used as default ones for the corresponding
+devices (if the address is free or a different address wasn't provided for the
+device):
+
+============  ==================
+0000:00:02.0  primary video card
+============  ==================
+
+
+For ``Q35`` the following devices are hard coded into QEMU and can't be moved
+or eliminated:
+
+============  =======================
+0000:00:00.0  Host bridge
+0000:00:1f.2  primary SATA controller
+0000:00:1f.0  ISA bridge
+0000:00:1f.3  SMBus
+============  =======================
+
+The following addresses will be used as default ones for the corresponding
+devices (if the address is free or a different address wasn't provided for the
+device) because that's how real ``Q35`` would do it:
+
+============  ===============
+0000:00:1a.0  USB2 controller
+0000:00:1b.0  ICH9 sound chip
+0000:00:1d.0  USB2 controller
+============  ===============
-- 
2.25.3

Re: [PATCH v2] docs: Document reserved PCI addresses for QEMU
Posted by Laine Stump 4 years ago
On 4/21/20 2:00 PM, Michal Privoznik wrote:
> >From time to time we are asked which PCI addresses are reserved
> in QEMU. Let's document them in one place, it's easier than
> reconstructing the list from the code each time.
>
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>
> diff to v1:
> - All Laine's comment worked in, hopefully.
>
>   docs/pci-addresses.rst | 50 ++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 50 insertions(+)
>
> diff --git a/docs/pci-addresses.rst b/docs/pci-addresses.rst
> index 885d50517a..4f123c7eb9 100644
> --- a/docs/pci-addresses.rst
> +++ b/docs/pci-addresses.rst
> @@ -235,3 +235,53 @@ guest OS rather than as ``0001:08:00.1``, which is the address of the
>   device on the host.
>   
>   Of course, all the rules and behaviors described above still apply.
> +
> +
> +Reserved addresses
> +==================
> +
> +Due to some historical reasons hypervisors might expect some PCI
> +devices to appear at certain addresses instead of 'random' ones.
> +For QEMU this is machine type and guest architecture dependant.
> +But to give you at least a gist here is list of reserved PCI
> +addresses:
> +
> +For ``I440FX`` the following devices are hard coded into QEMU and can't be
> +moved or eliminated:


Maybe instead of just saying "I440FX", you could say "the x86_64 
architecture's 'i440fx'-based machinetypes" (or something like that), 
both to let readers know that i440fx is a machinetype, as well as to 
indicate that this isn't the exact name of the machinetype, but a class 
of machinetypes.


> +
> +============  ======================
> +0000:00:00.0  Host bridge
> +0000:00:01.0  ISA bridge
> +0000:00:01.1  primary IDE controller
> +0000:00:01.2  PIIX3 USB controller
> +0000:00:01.3  ACPI (power management) and SMBus controller
> +============  ======================
> +
> +The following addresses will be used as default ones for the corresponding
> +devices (if the address is free or a different address wasn't provided for the
> +device):
> +
> +============  ==================
> +0000:00:02.0  primary video card
> +============  ==================


Do you think we need to explicitly say "it's okay to use this address 
for any other device"? Or is what's said here enough. I'm undecided, 
fine with it as is though.


> +
> +
> +For ``Q35`` the following devices are hard coded into QEMU and can't be moved
> +or eliminated:


Similar note for "q35" as for "i440fx"


> +
> +============  =======================
> +0000:00:00.0  Host bridge
> +0000:00:1f.2  primary SATA controller
> +0000:00:1f.0  ISA bridge
> +0000:00:1f.3  SMBus
> +============  =======================
> +
> +The following addresses will be used as default ones for the corresponding
> +devices (if the address is free or a different address wasn't provided for the
> +device) because that's how real ``Q35`` would do it:
> +
> +============  ===============
> +0000:00:1a.0  USB2 controller
> +0000:00:1b.0  ICH9 sound chip
> +0000:00:1d.0  USB2 controller
> +============  ===============


I notice you removed the dmi-to-pci-bridge. Which is fine with me, just 
wanted you to know that I know that you know ;-)


Reviewed-by: Laine Stump <laine@redhat.com>


Re: [PATCH v2] docs: Document reserved PCI addresses for QEMU
Posted by Michal Privoznik 4 years ago
On 4/24/20 3:46 AM, Laine Stump wrote:
> On 4/21/20 2:00 PM, Michal Privoznik wrote:
>> >From time to time we are asked which PCI addresses are reserved
>> in QEMU. Let's document them in one place, it's easier than
>> reconstructing the list from the code each time.
>>
>> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
>> ---
>>
>> diff to v1:
>> - All Laine's comment worked in, hopefully.
>>
>>   docs/pci-addresses.rst | 50 ++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 50 insertions(+)
>>
>> diff --git a/docs/pci-addresses.rst b/docs/pci-addresses.rst
>> index 885d50517a..4f123c7eb9 100644
>> --- a/docs/pci-addresses.rst
>> +++ b/docs/pci-addresses.rst
>> @@ -235,3 +235,53 @@ guest OS rather than as ``0001:08:00.1``, which 
>> is the address of the
>>   device on the host.
>>   Of course, all the rules and behaviors described above still apply.
>> +
>> +
>> +Reserved addresses
>> +==================
>> +
>> +Due to some historical reasons hypervisors might expect some PCI
>> +devices to appear at certain addresses instead of 'random' ones.
>> +For QEMU this is machine type and guest architecture dependant.
>> +But to give you at least a gist here is list of reserved PCI
>> +addresses:
>> +
>> +For ``I440FX`` the following devices are hard coded into QEMU and 
>> can't be
>> +moved or eliminated:
> 
> 
> Maybe instead of just saying "I440FX", you could say "the x86_64 
> architecture's 'i440fx'-based machinetypes" (or something like that), 
> both to let readers know that i440fx is a machinetype, as well as to 
> indicate that this isn't the exact name of the machinetype, but a class 
> of machinetypes.

Good point.

> 
> 
>> +
>> +============  ======================
>> +0000:00:00.0  Host bridge
>> +0000:00:01.0  ISA bridge
>> +0000:00:01.1  primary IDE controller
>> +0000:00:01.2  PIIX3 USB controller
>> +0000:00:01.3  ACPI (power management) and SMBus controller
>> +============  ======================
>> +
>> +The following addresses will be used as default ones for the 
>> corresponding
>> +devices (if the address is free or a different address wasn't 
>> provided for the
>> +device):
>> +
>> +============  ==================
>> +0000:00:02.0  primary video card
>> +============  ==================
> 
> 
> Do you think we need to explicitly say "it's okay to use this address 
> for any other device"? Or is what's said here enough. I'm undecided, 
> fine with it as is though.

I think "if the address is free" addresses that. But to be more explicit 
I'm adding what you suggested.

> 
> 
>> +
>> +
>> +For ``Q35`` the following devices are hard coded into QEMU and can't 
>> be moved
>> +or eliminated:
> 
> 
> Similar note for "q35" as for "i440fx"
> 
> 
>> +
>> +============  =======================
>> +0000:00:00.0  Host bridge
>> +0000:00:1f.2  primary SATA controller
>> +0000:00:1f.0  ISA bridge
>> +0000:00:1f.3  SMBus
>> +============  =======================
>> +
>> +The following addresses will be used as default ones for the 
>> corresponding
>> +devices (if the address is free or a different address wasn't 
>> provided for the
>> +device) because that's how real ``Q35`` would do it:
>> +
>> +============  ===============
>> +0000:00:1a.0  USB2 controller
>> +0000:00:1b.0  ICH9 sound chip
>> +0000:00:1d.0  USB2 controller
>> +============  ===============
> 
> 
> I notice you removed the dmi-to-pci-bridge. Which is fine with me, just 
> wanted you to know that I know that you know ;-)

Yes, that was intentional :-)

> 
> 
> Reviewed-by: Laine Stump <laine@redhat.com>
> 
> 

Pushed, thanks!

Michal