[PATCH libvirt v1 0/6] Fix ZPCI address auto-generation on s390

Andrea Bolognani abologna at redhat.com
Fri Apr 10 12:06:11 UTC 2020


On Thu, 2020-04-09 at 12:30 +0200, Shalini Chellathurai Saroja wrote:
> The ZPCI address validation or autogeneration does not work as
> expected in the following scenarios
> 1. uid = 0 and fid = 0
> 2. uid = 0 and fid > 0
> 3. uid = 0 and fid not specified
> 4. uid not specified and fid > 0
> 5. 2 ZPCI devices with uid > 0 and fid not specified.
> 
> This is because of the following reasons
> 1. If uid = 0 or fid = 0 the code assumes that user has not specified
>    the corresponding address
> 2. If either uid or fid is provided, the code assumes that both uid
>    and fid addresses are specified by the user.

I'd have to dig up the old threads, but based on what I remember the
behaviors you describe are entirely intentional.

For PCI addresses, setting all parts of the address to zero or not
setting it at all is equivalent, and we wanted to be consistent with
that behavior for ZPCI; additionally, zero is not a valid value for
uid so of course neither is the address uid=0 fid=0, which means that
we're not preventing the user from specifying a valid address by
conflating the all-zero address with the unspecified address.

For partially-specified addresses, the behavior is also the same as
PCI: any part you don't specify is considered to be zero, which
results in

  uid=0 fid=0 -> uid=0 fid=0 -> address gets autogenerated
  uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid
  uid=0       -> uid=0 fid=0 -> address gets autogenerated
        fid=x -> uid=0 fid=x -> address is rejected as invalid
  uid=x       -> uid=x fid=0 -> address is accepted

So, just like for PCI addresses, you have basically two reasonable
options: either don't specify any zPCI address and leave allocation
entirely up to libvirt, or specify all of the addresses completely:
anything in between will likely not work as you'd expect or want.

Again, this is based purely on my recollection of design discussions
that happened one and a half years ago, so I might have gotten some
of the details wrong - in which case by all means call me out on
that O:-)

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list