On Mon, Jun 17, 2024 at 08:24:40AM +0100, Richard W.M. Jones wrote: > On Wed, Jun 12, 2024 at 03:07:02PM +0100, Daniel P. Berrangé wrote: > > On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote: > > > On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote: > > > > > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users > > > > > > with older x86_64 hardware would likely be unable to run QEMU, from F41 > > > > > > onwards, unless some TBD action is taken. > > > > > > > > > > > > Thus I'm wondering whether Fedora has any policy or guidance on handling > > > > > > such a situation both in general, and more specifically for "critical path" > > > > > > packages, if that difference is relevant ? The packaging guidelines aren't > > > > > > especially explicit about this situation, unless I've missed something > > > > > > beyond the "compiler flags" and "architecture support" sections. > > > > > > > > > > > > > > > > Absent a project-wide decision to move to the newer baseline, I think > > > > > the best approach we can take would be to find some way to communicate > > > > > to the user that the software isn't usable. In the case of Qemu, does > > > > > the application report an error or crash if it's run on hardware > > > > > without the requisite baseline? > > > > > > > > I've not tested, but I would expect it to crash attempting to execute an > > > > illegal instruction > > > > > > > > > > OK, that's a situation that will lead to annoying and unresolvable bug > > > reports. Would it be possible to put something in place that would > > > check processor capabilities early in execution before hitting any of > > > the affected instructions? > > > > Not trivial as a bunch of code executes from ELF constructors before > > main() starts. > > A little known feature of GCC constructors if you can assign a > priority to them, which controls the ordering (apparently, I did not > test). Smaller numbers run the constructor earlier / destructor later: > > https://maskray.me/blog/2021-11-07-init-ctors-init-array > > Numbers <= 100 are reserved, but unless you opt in with the > -Wprio-ctor-dtor flag, you won't get a warning about this. Maybe we > can add a constructor(0) which checks CPUID? I think I've convinced upstream to change their approach to make their recent changes a compile-time opt-in, to allow build time choice of the non-optimized code, rather than forcing it on everyone. So hopefully we don't need todo anything in Fedora now. With 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 :| -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
