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