1 p.m.
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(a)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
8:46 p.m.
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(a)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(a)redhat.com>
2:55 a.m.
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(a)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(a)redhat.com>
Pushed, thanks!
Michal
1673
days inactive
1676
days old
2 comments
2 participants
participants (2)
-
Laine Stump -
Michal Privoznik