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 :|