On Fri, Jun 21, 2024 at 12:27:25PM -0400, Stephen Smoogen wrote:
> On Fri, 21 Jun 2024 at 07:27, Vít Ondruch wrote:
> > So what is the reason to not treat x86_64_v2 as different arch then
> > x86_64_v{1,3}. Why we keep having this discussion instead of fire one
> > more build? Users would need to
Dne 25. 06. 24 v 12:10 Dan Horák napsal(a):
On Tue, 25 Jun 2024 11:57:49 +0200
Vít Ondruch wrote:
Dne 24. 06. 24 v 20:03 Peter Robinson napsal(a):
On Mon, 24 Jun 2024 at 11:21, Vít Ondruch wrote:
Dne 21. 06. 24 v 18:27 Stephen Smoogen napsal(a):
On Fri, 21 Jun 2024 at 07:27, Vít Ondruch
On Tue, 25 Jun 2024 11:57:49 +0200
Vít Ondruch wrote:
>
> Dne 24. 06. 24 v 20:03 Peter Robinson napsal(a):
> > On Mon, 24 Jun 2024 at 11:21, Vít Ondruch wrote:
> >>
> >> Dne 21. 06. 24 v 18:27 Stephen Smoogen napsal(a):
> >>> On Fri, 21 Jun 2024 at 07:27, Vít Ondruch wrote:
> So what is
Dne 24. 06. 24 v 20:03 Peter Robinson napsal(a):
On Mon, 24 Jun 2024 at 11:21, Vít Ondruch wrote:
Dne 21. 06. 24 v 18:27 Stephen Smoogen napsal(a):
On Fri, 21 Jun 2024 at 07:27, Vít Ondruch wrote:
So what is the reason to not treat x86_64_v2 as different arch then
x86_64_v{1,3}. Why we
On Mon, 24 Jun 2024 at 11:21, Vít Ondruch wrote:
>
>
> Dne 21. 06. 24 v 18:27 Stephen Smoogen napsal(a):
> > On Fri, 21 Jun 2024 at 07:27, Vít Ondruch wrote:
> >> So what is the reason to not treat x86_64_v2 as different arch then
> >> x86_64_v{1,3}. Why we keep having this discussion instead of
Dne 21. 06. 24 v 18:27 Stephen Smoogen napsal(a):
On Fri, 21 Jun 2024 at 07:27, Vít Ondruch wrote:
So what is the reason to not treat x86_64_v2 as different arch then
x86_64_v{1,3}. Why we keep having this discussion instead of fire one
more build? Users would need to choose v1 / v2 / v3 ISO
On Fri, Jun 21, 2024 at 11:51 AM Dominik 'Rathann' Mierzejewski
wrote:
> If you mean Extended Page Table here
Yes, I used a shorthand term, since I am apparently
too steeped in the architectural details.
> I don't know any way to tell if my Cedar View Atom D2550 CPU from 2012
> supports it or
On Fri, 21 Jun 2024 at 07:27, Vít Ondruch wrote:
>
>
> So what is the reason to not treat x86_64_v2 as different arch then
> x86_64_v{1,3}. Why we keep having this discussion instead of fire one
> more build? Users would need to choose v1 / v2 / v3 ISO but what else?
>
>
I can think of three
On Friday, 21 June 2024 at 01:47, Gary Buhrmaster wrote:
> On Wed, Jun 19, 2024 at 8:39 AM Neal Gompa wrote:
[...]
> I will also note that since that -v1 desktop/laptop
> systems of the legacy architecture do not support
> EPT,
If you mean Extended Page Table here, then Wikipedia[1] says it was
On Thursday, 20 June 2024 at 19:50, Guinevere Larsen wrote:
> On 6/20/24 2:27 PM, Björn Persson wrote:
> > Stephen Gallagher wrote:
> > > On Thu, Jun 20, 2024 at 11:52 AM Chris Adams wrote:
> > > > Once upon a time, Stephen Gallagher said:
> > > > > three) and recommend creation of a Fedora
Dne 12. 06. 24 v 19:14 Neal Gompa napsal(a):
On Wed, Jun 12, 2024 at 4:00 PM Stephen Gallagher wrote:
On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé 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é wrote:
On Wed, Jun 19, 2024 at 8:39 AM Neal Gompa wrote:
> * I suspect more of the hardware that don't support -v2 have failed
> out of use naturally
Due to product line feature differentiation there
are more recent -v1 hardware than the aforementioned
roughly 2008 date, but the one pre-nehalem -v1
Once upon a time, Stephen Gallagher said:
> On Thu, Jun 20, 2024 at 11:52 AM Chris Adams wrote:
> > Once upon a time, Stephen Gallagher said:
> > > three) and recommend creation of a Fedora "Hardware Life Extension"
> > > Remix that can provide rebuilds of (a subset of) Fedora that they want
>
On 6/20/24 2:27 PM, Björn Persson wrote:
Stephen Gallagher wrote:
On Thu, Jun 20, 2024 at 11:52 AM Chris Adams wrote:
Once upon a time, Stephen Gallagher said:
three) and recommend creation of a Fedora "Hardware Life Extension"
Remix that can provide rebuilds of (a subset of) Fedora that
Stephen Gallagher wrote:
> On Thu, Jun 20, 2024 at 11:52 AM Chris Adams wrote:
> >
> > Once upon a time, Stephen Gallagher said:
> > > three) and recommend creation of a Fedora "Hardware Life Extension"
> > > Remix that can provide rebuilds of (a subset of) Fedora that they want
> > > to run
On Thu, Jun 20, 2024 at 3:52 PM Chris Adams wrote:
>
> Once upon a time, Stephen Gallagher said:
> > three) and recommend creation of a Fedora "Hardware Life Extension"
> > Remix that can provide rebuilds of (a subset of) Fedora that they want
> > to run on ancient hardware.
>
> TBH I feel that
On Thu, Jun 20, 2024 at 11:52 AM Chris Adams wrote:
>
> Once upon a time, Stephen Gallagher said:
> > three) and recommend creation of a Fedora "Hardware Life Extension"
> > Remix that can provide rebuilds of (a subset of) Fedora that they want
> > to run on ancient hardware.
>
> TBH I feel that
Once upon a time, Stephen Gallagher said:
> three) and recommend creation of a Fedora "Hardware Life Extension"
> Remix that can provide rebuilds of (a subset of) Fedora that they want
> to run on ancient hardware.
TBH I feel that approach would be doomed to the same failure as the
attempts to
On Thursday 20 June 2024 16:37:24 BST Tom Hughes wrote:
> On 20/06/2024 16:34, Simon Farnsworth wrote:
> > For Pentium and Celeron branded processors, v2 also loses Skylake,
> > Icelake,
> > Haswell, Cometlake, Broadwell and others, even when their matching Core
> > branded processors support
On 20/06/2024 16:34, Simon Farnsworth wrote:
For Pentium and Celeron branded processors, v2 also loses Skylake, Icelake,
Haswell, Cometlake, Broadwell and others, even when their matching Core
branded processors support x86-64v2 or x86-64v3.
That means that you lose all Pentium Silver
On Thursday 20 June 2024 15:48:55 BST Daniel P. Berrangé wrote:
> On Thu, Jun 20, 2024 at 03:24:18PM +0100, Tom Hughes via devel wrote:
>
> > On 20/06/2024 15:03, Stephen Gallagher wrote:
> >
> >
> > > Honestly, I'd like to pitch that we retarget Fedora at x86_64-v3 (yes,
> > > three) and
On Thu, Jun 20, 2024 at 10:51:56AM -0400, Stephen Gallagher wrote:
> On Thu, Jun 20, 2024 at 10:49 AM Daniel P. Berrangé
> wrote:
> >
> > On Thu, Jun 20, 2024 at 03:24:18PM +0100, Tom Hughes via devel wrote:
> > > On 20/06/2024 15:03, Stephen Gallagher wrote:
> > >
> > > > Honestly, I'd like to
On Thu, Jun 20, 2024 at 10:49 AM Daniel P. Berrangé wrote:
>
> On Thu, Jun 20, 2024 at 03:24:18PM +0100, Tom Hughes via devel wrote:
> > On 20/06/2024 15:03, Stephen Gallagher wrote:
> >
> > > Honestly, I'd like to pitch that we retarget Fedora at x86_64-v3 (yes,
> > > three) and recommend
On Thu, Jun 20, 2024 at 03:24:18PM +0100, Tom Hughes via devel wrote:
> On 20/06/2024 15:03, Stephen Gallagher wrote:
>
> > Honestly, I'd like to pitch that we retarget Fedora at x86_64-v3 (yes,
> > three) and recommend creation of a Fedora "Hardware Life Extension"
> > Remix that can provide
On 20/06/2024 15:03, Stephen Gallagher wrote:
Honestly, I'd like to pitch that we retarget Fedora at x86_64-v3 (yes,
three) and recommend creation of a Fedora "Hardware Life Extension"
Remix that can provide rebuilds of (a subset of) Fedora that they want
to run on ancient hardware. It could be
On Thu, Jun 20, 2024 at 8:49 AM Chris Adams wrote:
>
> Once upon a time, Stephen Smoogen said:
> > I don't think Peter meant additional packages since with the i686 it
> > didn't mean that. What it did mean was having to understand why two
> > architectures might do things differently and why
Once upon a time, Stephen Smoogen said:
> I don't think Peter meant additional packages since with the i686 it
> didn't mean that. What it did mean was having to understand why two
> architectures might do things differently and why bugs might show up
> in one but not another.
In the i686 days,
On Thu, Jun 20, 2024 at 7:30 AM Stephen Smoogen wrote:
>
> On Wed, 19 Jun 2024 at 16:23, Fabio Valentini wrote:
> >
> > On Wed, Jun 19, 2024 at 8:40 PM Peter Robinson wrote:
> > >
> > > On Wed, 19 Jun 2024 at 19:13, Dominik 'Rathann' Mierzejewski
> > > wrote:
> > > >
> > > > On Wednesday, 19
On Wed, 19 Jun 2024 at 16:23, Fabio Valentini wrote:
>
> On Wed, Jun 19, 2024 at 8:40 PM Peter Robinson wrote:
> >
> > On Wed, 19 Jun 2024 at 19:13, Dominik 'Rathann' Mierzejewski
> > wrote:
> > >
> > > On Wednesday, 19 June 2024 at 17:17, drago01 wrote:
> > > > [...] at some point we need to
On Wed, Jun 19, 2024 at 8:40 PM Peter Robinson wrote:
>
> On Wed, 19 Jun 2024 at 19:13, Dominik 'Rathann' Mierzejewski
> wrote:
> >
> > On Wednesday, 19 June 2024 at 17:17, drago01 wrote:
> > > [...] at some point we need to do the cut and not being held back by old
> > > / ancient hardware
On Wed, 19 Jun 2024 at 19:13, Dominik 'Rathann' Mierzejewski
wrote:
>
> On Wednesday, 19 June 2024 at 17:17, drago01 wrote:
> > [...] at some point we need to do the cut and not being held back by old
> > / ancient hardware forever.
>
> What do you mean by "being held back"? What's being
On Thu, 13 Jun 2024 at 13:58, Chris Adams wrote:
>
> Once upon a time, Ben Cotton said:
> > For myself, I think it's reasonable to conclude there's a non-trivial
> > amount of people using QEMU on that hardware in some fashion. Much of
> > that is probably from podman as opposed to running large
On Wednesday, 19 June 2024 at 17:17, drago01 wrote:
> [...] at some point we need to do the cut and not being held back by old
> / ancient hardware forever.
What do you mean by "being held back"? What's being prevented by not
requiring x86-64-v2 for all packages while allowing few select ones to
Please note that switching to x86_64-v2 does *not* give you access to
AVX2 or even AVX. It stops at SSE4.2 with POPCNT.
AVX2 means x86_64-v3, which both excludes a lot more hardware and allows
(in some cases) much more significant performance gains.
On 6/19/24 3:29 AM, Vitaly Zaitsev via
On Wednesday, June 19, 2024, Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:
> On Wednesday, 19 June 2024 at 10:39, Neal Gompa wrote:
> > On Wed, Jun 19, 2024 at 9:29 AM Vitaly Zaitsev via devel
> > wrote:
> > >
> > > On 19/06/2024 09:13, Daniel P. Berrangé wrote:
> > > > If
On Wednesday, 19 June 2024 at 10:39, Neal Gompa wrote:
> On Wed, Jun 19, 2024 at 9:29 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 19/06/2024 09:13, Daniel P. Berrangé wrote:
> > > If Fedora cares
> > > about optimal performance it should just declare we're going to stop
> > > being held back
On Wed, Jun 19, 2024 at 9:29 AM Vitaly Zaitsev via devel
wrote:
>
> On 19/06/2024 09:13, Daniel P. Berrangé wrote:
> > If Fedora cares
> > about optimal performance it should just declare we're going to stop
> > being held back by compat with ancient hardware and use -v2 baseline
> > for
On 19/06/2024 09:13, Daniel P. Berrangé wrote:
If Fedora cares
about optimal performance it should just declare we're going to stop
being held back by compat with ancient hardware and use -v2 baseline
for everything, but obviously that's been rejected previously.
Maybe it's a good time for the
On Mon, Jun 17, 2024 at 07:37:15AM -0500, Chris Adams wrote:
> Once upon a time, Daniel P. Berrangé said:
> > 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
On Mon, Jun 17, 2024 at 2:37 PM Chris Adams wrote:
>
> Once upon a time, Daniel P. Berrangé said:
> > 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
Once upon a time, Daniel P. Berrangé said:
> 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
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é
> > > 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é
> > wrote:
> > >
> > > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
> > > > On
Gary Buhrmaster wrote:
> Please provide your audited (by a 3rd party) data that shows
> that MANY (i.e. significant percentage of) people on x86_64-v1
> users have a need for qemu.
"Many people" was just an estimate considering that QEMU is a popular
package, so it is more likely to be used in
On 6/13/24 10:14 AM, Chris Adams wrote:
Once upon a time, Björn Persson said:
If this will affect containers, then I'm starting to worry that I might
be affected. I thought I'd be fine as the computers I run virtual
machines on are x86-64-v2 and -v3, but another computer that still
works fine
Chris Adams wrote:
> Once upon a time, Björn Persson said:
> > If this will affect containers, then I'm starting to worry that I might
> > be affected. I thought I'd be fine as the computers I run virtual
> > machines on are x86-64-v2 and -v3, but another computer that still
> > works fine is
Once upon a time, Björn Persson said:
> If this will affect containers, then I'm starting to worry that I might
> be affected. I thought I'd be fine as the computers I run virtual
> machines on are x86-64-v2 and -v3, but another computer that still
> works fine is -v1. As popular as containers
Ben Cotton wrote:
> For myself, I think it's reasonable to conclude there's a non-trivial
> amount of people using QEMU on that hardware in some fashion. Much of
> that is probably from podman as opposed to running large virtualized
> environments at this point, but the podman use case is
> On 13 Jun 2024, at 14:54, Jerry James wrote:
>
> Wikipedia has some information:
> https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
After asking I did some more web searches and come up with
In this article: https://medium.com/@BetterIsHeather/x86-64-levels-944e92cd6d83
it
On Thu, Jun 13, 2024 at 7:50 AM Barry Scott wrote:
> Where is the v2, v3 etc levels specified?
>
> I've not been able to web search and find a spec.
>
> Is this called an x64-64 micro-architecture?
>
> Armed with a spec it might be possible to search on ark.intel.com.
Wikipedia has some
> On 13 Jun 2024, at 13:58, Chris Adams wrote:
>
> Without knowing which CPU models are actually affected, I don't think
> it's reasonable to draw any conclusions.
Where is the v2, v3 etc levels specified?
I've not been able to web search and find a spec.
Is this called an x64-64
Once upon a time, Ben Cotton said:
> For myself, I think it's reasonable to conclude there's a non-trivial
> amount of people using QEMU on that hardware in some fashion. Much of
> that is probably from podman as opposed to running large virtualized
> environments at this point, but the podman
On Thu, Jun 13, 2024 at 11:44 AM Ben Cotton wrote:
>
> On Wed, Jun 12, 2024 at 10:51 PM Gary Buhrmaster
> wrote:
> >
> > On Thu, Jun 13, 2024 at 1:35 AM Kevin Kofler via devel
> > wrote:
> >
> > > But it is the ONLY approach that is compatible with Fedora policies, and
> > > as
> > > such
On Wed, Jun 12, 2024 at 10:51 PM Gary Buhrmaster
wrote:
>
> On Thu, Jun 13, 2024 at 1:35 AM Kevin Kofler via devel
> wrote:
>
> > But it is the ONLY approach that is compatible with Fedora policies, and as
> > such should be required. ESPECIALLY for a package like QEMU that many people
> > are
Could you by any chance link to the commit that introduces this issue? I'd like
to bring this to the awareness of core devs in Ubuntu.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Thu, Jun 13, 2024 at 1:35 AM Kevin Kofler via devel
wrote:
> But it is the ONLY approach that is compatible with Fedora policies, and as
> such should be required. ESPECIALLY for a package like QEMU that many people
> are using.
Please provide your audited (by a 3rd party) data that shows
Daniel P. Berrangé wrote:
> It isn't as simple as changing the CFLAGS. QEMU used to check for
> the CPU feature at startup, set a flag, and then later use that flag
> to choose different codepaths, but this logic was removed. Avoiding
> the flag check in hot-paths makes a perf difference.
>
> So
Chris Adams wrote:
> Once upon a time, Neal Gompa said:
>> We may also want to start having a conversation about moving to
>> x86_64-v2 RPM arch for x86_64 across the board if we're going to start
>> encountering stuff like this.
>
> Is there a good decoder ring for which CPUs are which level?
Once upon a time, Neal Gompa said:
> We may also want to start having a conversation about moving to
> x86_64-v2 RPM arch for x86_64 across the board if we're going to start
> encountering stuff like this.
Is there a good decoder ring for which CPUs are which level? Looking at
all my systems, I
On Wed, Jun 12, 2024 at 9:15 PM Przemek Klosowski via devel
wrote:
>
> On 6/12/24 14:07, Ben Cotton wrote:
> > Yeah, maintaining that long-term seems like a bad idea. [...] But it
> > would at least buy us some time so that we don't end up with the
> > "surprise, you can't use this release on
On 6/12/24 14:07, Ben Cotton wrote:
Yeah, maintaining that long-term seems like a bad idea. [...] But it
would at least buy us some time so that we don't end up with the
"surprise, you can't use this release on your hardware if you want to
use QEMU!" situation.
The root cause seems to be the
On Wed, Jun 12, 2024 at 6:08 PM Ben Cotton wrote:
> But it
> would at least buy us some time so that we don't end up with the
> "surprise, you can't use this release on your hardware if you want to
> use QEMU!" situation.
Since we don't have complete instrumentation, we
really don't know
* Daniel P. Berrangé:
> On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote:
>> 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
On Wed, Jun 12, 2024 at 12:35 PM Daniel P. Berrangé wrote:
>
> It isn't as simple as changing the CFLAGS. QEMU used to check for
> the CPU feature at startup, set a flag, and then later use that flag
> to choose different codepaths, but this logic was removed. Avoiding
> the flag check in
On Wed, Jun 12, 2024 at 4:00 PM Stephen Gallagher wrote:
>
> On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé
> 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é
> > > wrote:
> > > > IOW, if [when] we
On Wed, Jun 12, 2024 at 05:35:24PM +0100, Daniel P. Berrangé wrote:
> It isn't as simple as changing the CFLAGS. QEMU used to check for
> the CPU feature at startup, set a flag, and then later use that flag
> to choose different codepaths, but this logic was removed. Avoiding
> the flag check in
On Wed, Jun 12, 2024 at 11:50:00AM -0400, Ben Cotton wrote:
> On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé
> wrote:
> >
> > The context is that QEMU has recently merged changes upstream that force
> > use of the x86-64-v2 baseline for QEMU, in order get more efficient code
> > in the TCG
On Wed, Jun 12, 2024 at 3:50 PM Ben Cotton wrote:
> Neither "Functional" nor "eFficient" are in the Fedora Foundations,
> but in general, I think we should prefer the former over the latter.
> It's better for the project overall to be a little less efficient than
> it could be than to surprise
On Wed, Jun 12, 2024 at 5:47 PM Daniel P. Berrangé wrote:
>
> On Wed, Jun 12, 2024 at 10:05:13AM -0400, Ben Beasley wrote:
> > This never made it to the packaging guidelines, but FESCo made a relevant
> > decision a few years ago:
> >
> > Libraries packaged in Fedora may require ISA extensions,
On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé wrote:
>
> The context is that QEMU has recently merged changes upstream that force
> use of the x86-64-v2 baseline for QEMU, in order get more efficient code
> in the TCG emulator. The changes were made in QEMU's global CFLAGS so this
> will
On Wed, Jun 12, 2024 at 10:05:13AM -0400, Ben Beasley wrote:
> This never made it to the packaging guidelines, but FESCo made a relevant
> decision a few years ago:
>
> Libraries packaged in Fedora may require ISA extensions, however any
> packaged application must not crash on any officially
On Wed, Jun 12, 2024 at 10:07 AM 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é
> > wrote:
> > >
> > > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:
> > > > On Wed, Jun
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é
> 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é
> > > wrote:
> > > > IOW, if
This never made it to the packaging guidelines, but FESCo made a
relevant decision a few years ago:
Libraries packaged in Fedora may require ISA extensions, however any
packaged application must not crash on any officially supported
architecture, either by providing a generic fallback
On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé 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é
> > wrote:
> > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, users
> > > with older
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é
> 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,
On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé wrote:
>
> There have been various change proposals & associated mailing list threads
> over the years about the possibility of moving Fedora compiler toolchain
> to build with a newer x86_64 baseline ABI, which have ended up rejected,
> with
There have been various change proposals & associated mailing list threads
over the years about the possibility of moving Fedora compiler toolchain
to build with a newer x86_64 baseline ABI, which have ended up rejected,
with some quite strong negative feedback.
Regardless of the Fedora general
78 matches
Mail list logo
