The idea behind this document is to show, with actual examples,
that users should not expect PCI addresses in the domain XML and
in the guest OS to match.
The first zPCI example already serves this purpose perfectly, so
in the interest of keeping the page as brief and easy to digest
as possible the second one is removed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
docs/pci-addresses.rst | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/docs/pci-addresses.rst b/docs/pci-addresses.rst
index 86a41df6ce..1d2dc8e5fc 100644
--- a/docs/pci-addresses.rst
+++ b/docs/pci-addresses.rst
@@ -204,25 +204,6 @@ will result in the exactly same view in the guest, as the addresses there
are generated from the information provided via the ``zpci`` element (in
fact, from the ``uid``).
-Therefore, replacing the virtio-net device definition with the following XML
-snippet
-
-::
-
- <interface type='bridge'>
- <source bridge='virbr0'/>
- <model type='virtio'/>
- <address type='pci' domain='0x0000' bus='0x01' slot='0x07' function='0x3'>
- <zpci uid='0x0007' fid='0x00000003'/>
- </address>
- </interface>
-
-will yield the following result in a Linux guest:
-
-::
-
- 0007:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device
-
Device assignment
=================
--
2.25.2
On Wed, 15 Apr 2020 19:31:36 +0200 Andrea Bolognani <abologna@redhat.com> wrote: > The idea behind this document is to show, with actual examples, > that users should not expect PCI addresses in the domain XML and > in the guest OS to match. > > The first zPCI example already serves this purpose perfectly, so > in the interest of keeping the page as brief and easy to digest > as possible the second one is removed. > > Signed-off-by: Andrea Bolognani <abologna@redhat.com> > --- > docs/pci-addresses.rst | 19 ------------------- > 1 file changed, 19 deletions(-) > > diff --git a/docs/pci-addresses.rst b/docs/pci-addresses.rst > index 86a41df6ce..1d2dc8e5fc 100644 > --- a/docs/pci-addresses.rst > +++ b/docs/pci-addresses.rst > @@ -204,25 +204,6 @@ will result in the exactly same view in the guest, as the addresses there > are generated from the information provided via the ``zpci`` element (in > fact, from the ``uid``). > > -Therefore, replacing the virtio-net device definition with the following XML > -snippet > - > -:: > - > - <interface type='bridge'> > - <source bridge='virbr0'/> > - <model type='virtio'/> > - <address type='pci' domain='0x0000' bus='0x01' slot='0x07' function='0x3'> > - <zpci uid='0x0007' fid='0x00000003'/> > - </address> > - </interface> > - > -will yield the following result in a Linux guest: > - > -:: > - > - 0007:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device > - > > Device assignment > ================= Hm, should that rather go somewhere else? What I wanted to show is "you can have the same PCI address in the XML and still get a different PCI address in the guest, if you change the zpci values", as that might be another source of confusion.
On Wed, 2020-04-15 at 19:47 +0200, Cornelia Huck wrote: > On Wed, 15 Apr 2020 19:31:36 +0200 > Andrea Bolognani <abologna@redhat.com> wrote: > > -Therefore, replacing the virtio-net device definition with the following XML > > -snippet > > - > > -:: > > - > > - <interface type='bridge'> > > - <source bridge='virbr0'/> > > - <model type='virtio'/> > > - <address type='pci' domain='0x0000' bus='0x01' slot='0x07' function='0x3'> > > - <zpci uid='0x0007' fid='0x00000003'/> > > - </address> > > - </interface> > > - > > -will yield the following result in a Linux guest: > > - > > -:: > > - > > - 0007:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device > > Hm, should that rather go somewhere else? What I wanted to show is "you > can have the same PCI address in the XML and still get a different PCI > address in the guest, if you change the zpci values", as that might be > another source of confusion. I think the previous example, specifically the last bit where you explain how changing the PCI address completely in the domain XML would not change what the guest OS sees because the latter is derived from uid and fid, already drives the point home. It's really two sides of the same coin. Additionally, as I explained elsewhere, this document is not meant to list every possible situation in which PCI addresses in the domain XML and in the guest OS are out of sync, but merely to show that such cases exist. It's valuable to mention the zPCI scenario, but we don't need to show more than one variation of it in my opinion. -- Andrea Bolognani / Red Hat / Virtualization
On Thu, 16 Apr 2020 09:28:58 +0200 Andrea Bolognani <abologna@redhat.com> wrote: > On Wed, 2020-04-15 at 19:47 +0200, Cornelia Huck wrote: > > On Wed, 15 Apr 2020 19:31:36 +0200 > > Andrea Bolognani <abologna@redhat.com> wrote: > > > -Therefore, replacing the virtio-net device definition with the following XML > > > -snippet > > > - > > > -:: > > > - > > > - <interface type='bridge'> > > > - <source bridge='virbr0'/> > > > - <model type='virtio'/> > > > - <address type='pci' domain='0x0000' bus='0x01' slot='0x07' function='0x3'> > > > - <zpci uid='0x0007' fid='0x00000003'/> > > > - </address> > > > - </interface> > > > - > > > -will yield the following result in a Linux guest: > > > - > > > -:: > > > - > > > - 0007:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device > > > > Hm, should that rather go somewhere else? What I wanted to show is "you > > can have the same PCI address in the XML and still get a different PCI > > address in the guest, if you change the zpci values", as that might be > > another source of confusion. > > I think the previous example, specifically the last bit where you > explain how changing the PCI address completely in the domain XML > would not change what the guest OS sees because the latter is derived > from uid and fid, already drives the point home. It's really two > sides of the same coin. > > Additionally, as I explained elsewhere, this document is not meant to > list every possible situation in which PCI addresses in the domain > XML and in the guest OS are out of sync, but merely to show that such > cases exist. It's valuable to mention the zPCI scenario, but we don't > need to show more than one variation of it in my opinion. > Fair enough. Reviewed-by: Cornelia Huck <cohuck@redhat.com>
On 4/15/20 7:47 PM, Cornelia Huck wrote:
> On Wed, 15 Apr 2020 19:31:36 +0200
> Andrea Bolognani <abologna@redhat.com> wrote:
>
>> The idea behind this document is to show, with actual examples,
>> that users should not expect PCI addresses in the domain XML and
>> in the guest OS to match.
>>
>> The first zPCI example already serves this purpose perfectly, so
>> in the interest of keeping the page as brief and easy to digest
>> as possible the second one is removed.
>>
>> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
>> ---
>> docs/pci-addresses.rst | 19 -------------------
>> 1 file changed, 19 deletions(-)
>>
>> diff --git a/docs/pci-addresses.rst b/docs/pci-addresses.rst
>> index 86a41df6ce..1d2dc8e5fc 100644
>> --- a/docs/pci-addresses.rst
>> +++ b/docs/pci-addresses.rst
>> @@ -204,25 +204,6 @@ will result in the exactly same view in the guest, as the addresses there
>> are generated from the information provided via the ``zpci`` element (in
>> fact, from the ``uid``).
>>
>> -Therefore, replacing the virtio-net device definition with the following XML
>> -snippet
>> -
>> -::
>> -
>> - <interface type='bridge'>
>> - <source bridge='virbr0'/>
>> - <model type='virtio'/>
>> - <address type='pci' domain='0x0000' bus='0x01' slot='0x07' function='0x3'>
>> - <zpci uid='0x0007' fid='0x00000003'/>
>> - </address>
>> - </interface>
>> -
>> -will yield the following result in a Linux guest:
>> -
>> -::
>> -
>> - 0007:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device
>> -
I suggest to use the zpci addressing from the removed example because it
outlines more clearly the differences in the parameters.
Something like the example below:
For s390x machines, PCI addresses are handled yet differently. No
topology information is relayed in the PCI addresses; instead, the fid
and uid elements of the zpci device convey information. In the simplest
case, the following XML snippet
<controller type='pci' index='0' model='pci-root'/>
<controller type='pci' index='1' model='pci-bridge'>
<model name='pci-bridge'/>
<target chassisNr='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01'
function='0x0'>
<zpci uid='0x0001' fid='0x00000000'/>
</address>
</controller>
<interface type='bridge'>
<mac address='02:ca:fe:fa:ce:04'/>
<source bridge='virbr0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x01'
function='0x0'>
<zpci uid='0x0007' fid='0x00000003'/>
</address>
</interface>
will result in the following in a Linux guest:
0007:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device
The slot for the PCI device in the guest OS is defined by the fid
(function id).
>>
>> Device assignment
>> =================
>
> Hm, should that rather go somewhere else? What I wanted to show is "you
> can have the same PCI address in the XML and still get a different PCI
> address in the guest, if you change the zpci values", as that might be
> another source of confusion.
>
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
On Thu, 2020-04-16 at 12:29 +0200, Boris Fiuczynski wrote: > I suggest to use the zpci addressing from the removed example because it > outlines more clearly the differences in the parameters. > Something like the example below: > > For s390x machines, PCI addresses are handled yet differently. No > topology information is relayed in the PCI addresses; instead, the fid > and uid elements of the zpci device convey information. In the simplest > case, the following XML snippet > > <controller type='pci' index='0' model='pci-root'/> > <controller type='pci' index='1' model='pci-bridge'> > <model name='pci-bridge'/> > <target chassisNr='1'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' > function='0x0'> > <zpci uid='0x0001' fid='0x00000000'/> > </address> > </controller> > <interface type='bridge'> > <mac address='02:ca:fe:fa:ce:04'/> > <source bridge='virbr0'/> > <model type='virtio'/> > <address type='pci' domain='0x0000' bus='0x01' slot='0x01' > function='0x0'> > <zpci uid='0x0007' fid='0x00000003'/> > </address> > </interface> > > will result in the following in a Linux guest: > > 0007:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device You're right, this example is more illustrative. Care to submit a patch changing it? -- Andrea Bolognani / Red Hat / Virtualization
© 2016 - 2026 Red Hat, Inc.