On Tue, 2018-08-21 at 19:55 +0800, Yi Min Zhao wrote:
在 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.
In the context of PCI addresses, empty implies invalid but during
XML parsing the address is only validated if it's not empty. If
that was not the case, an empty address would never have a chance
to be automatically filled in by libvirt :)
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).
I asked a question about this in reply to patch 09/12 yesterday
by the way, and it would be great if you could answer it.
> > 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 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.
This would be the same as specifying a partial PCI address such as
<address type='pci' slot='0x00'/>
and getting an address with slot != 0x00 back: surprising, perhaps,
but that's the way it's been with PCI addresses forever so you can
assume users are familiar with it by now.
For zPCI addresses to be inconsistent with this behavior would be
utterly confusing; moreover, if the user really needs the uid and
fid to have certain values, all they have to do is specify both
and libvirt will not attempt to override them.
--
Andrea Bolognani / Red Hat / Virtualization