[libvirt] [PATCH v3 01/12] conf: Add definitions for 'uid' and 'fid' PCI address attributes

[Yi Min Zhao]

在 2018/8/21 下午7:00, Andrea Bolognani 写道:
> On Tue, 2018-08-21 at 17:35 +0800, Yi Min Zhao wrote:
>> I want to ask a question. For pci address, any pci device can't use slot 0.
>> Is that a reason why PCI part could treat all zeros as empty address?
> A PCI address where all attributes are zero can't be used, so
> there's no ambiguity there; same for a zPCI address where all
> attributes are zero, which also can't be used.
Yes, uid must be non-zero value. But the user could only define fid like
you mentioned below. Validation check happens during parsing xml.
So if the user only defines fid=0, zpci address (fid=0, uid=0 although the
user doesn't specify uid value) is going to be invalid as PCI address
check logic. UID and FID must be unique separately, but we can't treat
them as a combination. This doesn't like PCI 
address(domain:bus:slot:function).
>
>> For zPCI address, if we use the same strategy as PCI part and user
>> wants to assign fid=0 to the specific device, he might encounter
>> assignment failure. At least, according to the doc, 0 shoud be a valid
>> value to assign to fid.
> If the user wants to use a specific zPCI address they can simply
> specify both attributes, eg. uid=1,fid=0 will work just fine with
> the proposed approach and won't produce errors or cause a new zPCI
> address to be automatically assigned.
>
> If the user only specified fid=0 while leaving uid unspecified,
> well, an address is going to be picked for them. This is consistent
This would be an empty zpci address while parsing XML so that we might
pick a zpci address with non-zero fid. For example:

dev1: fid=0 (this address would be treated as an unassigned zpci address)
dev2 (no definition for both fid and uid)

Then the process of assigning addresses will iterate devices as type by 
type.
If dev2 is processed before dev1, dev2's fid would be assigned by 0. 
This causes
dev1's fid=1. The result doesn't match what the user wants.
> with how PCI addresses are treated so it shouldn't be a problem: if
> anything, *deviating* from this behavior would cause confusion.
>