On Tue, May 12, 2020 at 12:13:22PM +0200, Boris Fiuczynski wrote:
On 5/7/20 5:51 PM, Laine Stump wrote:
> In any case, it sounds like current behavior for zPCI is broken for some
> use cases, and imo this is new enough and usage is narrow enough that if
> the maintainers (who I would guess represent the actual users) think
> fixing the bug is more important than 100% backward compatibility in a
> corner case, then they should be able to change it.
I would like to get this fixed such that the behavior is architecture
compliant.
The behavior change would be
Current code:
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
IIUC, in the two cases here where the address gets auto-generated,
the resulting guest VM successfully boots & runs....
With the series applied
uid=0 fid=0 -> uid=0 fid=0 -> address is rejected as invalid
uid=0 fid=x -> uid=0 fid=x -> address is rejected as invalid
uid=0 -> uid=0 fid=0 -> address is rejected as invalid
...so this proposed change is a functional regression for the
user.
The documentation already specifies the uid value range correctly.
The fix for users hitting the two scenarios (uid=0 fid=0) and (uid=0) is
simple: Remove the zpci definition completely.
This would be taking a users' currently working VM, intentionally
breaking it, and then making the user pick up the pieces. This is
an example of a behaviour regression that libvirt promises to not
do to users.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|