From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"David Michael" <fedora.dm0@gmail.com>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH] configure: map x32 to cpu_family x86_64 for meson
Date: Wed, 9 Jun 2021 14:48:09 +0100 [thread overview]
Message-ID: <YMDGmRRx89bCA7ds@redhat.com> (raw)
In-Reply-To: <CAFEAcA-4cakv+K2D0Fy67kFrY3J4SdDUJJ=J89Pp-YX5n=3WvA@mail.gmail.com>
On Wed, Jun 09, 2021 at 02:30:09PM +0100, Peter Maydell wrote:
> On Wed, 9 Jun 2021 at 13:48, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Wed, Jun 09, 2021 at 08:28:39AM -0400, David Michael wrote:
> > > The meson.build file defines supported_cpus which does not contain
> > > x32, and x32 is not one of meson's stable built-in values:
> > > https://mesonbuild.com/Reference-tables.html#cpu-families
> > >
> > > Signed-off-by: David Michael <fedora.dm0@gmail.com>
> > > ---
> > >
> > > Hi,
> > >
> > > QEMU fails to build for x32 due to that cpu_family not being defined in
> > > supported_cpus. Can something like this be applied?
> > >
> > > Alternatively, maybe it could be added to supported_cpus and accepted
> > > everywhere that matches x86 in meson.build, but upstream meson does not
> > > define a CPU type for x32.
> >
> > "supported_cpus" serves two distinct purposes in meson.build
> >
> > - Identifies whether TCG supports the target
> > - Identifies whether QEMU maintainers consider the target supported
> >
> > The change proposed below makes x32 be treated the same as x86_64.
>
> I feel like it's more "fixing a regression we introduced by accident
> at some point". Looking at the 5.1 configure script (which predates
> the meson conversion) x32 is marked as a supported cpu. Currently it
> isn't, so that's a regression. (I don't have the setup to bisect that
> right now, but it would be interesting to confirm where it stopped
> working.) Whether we feel that we no longer want to support x32 is
> a separate question and we'd need to go through our usual deprecation
> process if we did want to drop it.
Ah, I missed that it was previously working.
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 :|
next prev parent reply other threads:[~2021-06-09 13:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 12:28 [PATCH] configure: map x32 to cpu_family x86_64 for meson David Michael
2021-06-09 12:45 ` Daniel P. Berrangé
2021-06-09 13:00 ` David Michael
2021-06-09 13:30 ` Peter Maydell
2021-06-09 13:48 ` Daniel P. Berrangé [this message]
2021-06-11 17:09 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YMDGmRRx89bCA7ds@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=fedora.dm0@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.