From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"open list:RISC-V" <qemu-riscv@nongnu.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
qemu-discuss <qemu-discuss@nongnu.org>,
qemu-s390x <qemu-s390x@nongnu.org>,
qemu-arm <qemu-arm@nongnu.org>,
qemu-ppc@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [RFC PATCH] configure: deprecate 32 bit build hosts
Date: Mon, 30 Sep 2019 10:25:42 +0100 [thread overview]
Message-ID: <20190930092519.GB11996@redhat.com> (raw)
In-Reply-To: <4512b61a-ed82-e628-88e5-f44ef87c2b50@linaro.org>
On Thu, Sep 26, 2019 at 10:11:05AM -0700, Richard Henderson wrote:
> On 9/26/19 12:50 AM, Peter Maydell wrote:
> > On Thu, 26 Sep 2019 at 00:31, Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >> The 32 bit hosts are already a second class citizen especially with
> >> support for running 64 bit guests under TCG. We are also limited by
> >> testing as actual working 32 bit machines are getting quite rare in
> >> developers personal menageries. For TCG supporting newer types like
> >> Int128 is a lot harder with 32 bit calling conventions compared to
> >> their larger bit sized cousins. Fundamentally address space is the
> >> most useful thing for the translator to have even for a 32 bit guest a
> >> 32 bit host is quite constrained.
> >>
> >> As far as I'm aware 32 bit KVM users are even less numerous. Even
> >> ILP32 doesn't make much sense given the address space QEMU needs to
> >> manage.
> >
> > For KVM we should wait until the kernel chooses to drop support,
> > I think.
>
> Agreed. I think this discussion should be more about TCG.
>
> >> @@ -745,19 +744,22 @@ case "$cpu" in
> >> ;;
> >> armv*b|armv*l|arm)
> >> cpu="arm"
> >> - supported_cpu="yes"
> >> ;;
> >
> > I'll leave others to voice opinions about their architectures,
> > but I still have 32-bit arm in my test set for builds, and
> > I'm pretty sure we have users (raspi users, for a start).
>
> I'd really like to know what raspi users might be using qemu for. Depending on
> that answer, perhaps it would be sufficient for arm32 tcg to only support
> 32-bit guests.
I asked on the Fedora development lists for feedback on the idea of
dropping QEMU 32-bit host support
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/TPAVIC6YANGP2NK4RUOP7OCIOIFIOV3A/
The response was rather underwhealming to say the least, with only one
person explicitly expressing a desire for QEMU to keep 32-bit host
support for armv7l.
The main interesting thing I learnt was that even with 64-bit Raspberry
Pi hardware, it can be desirable to run 32-bit Raspberry Pi supporting
distro, supposedly for performance benefits.
> For context, the discussion that Alex and I were having was about int128_t, and
> how to support that directly in tcg (especially to/from helpers), and how that
> might be vastly easier if we didn't have to consider 32-bit hosts.
I know nothing about TCG internals, but Is it viable to implement int128_t
support only in 64-bit host, leaving 32-bit hosts without it ? Or is this
really a blocking item that is holding back 64-bit host features.
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:[~2019-09-30 9:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 23:30 [RFC PATCH] configure: deprecate 32 bit build hosts Alex Bennée
2019-09-26 7:29 ` Philippe Mathieu-Daudé
2019-09-26 7:50 ` Peter Maydell
2019-09-26 12:58 ` Daniel P. Berrangé
2019-09-26 13:46 ` Christian Borntraeger
2019-09-26 14:26 ` Thomas Huth
2019-09-26 15:27 ` Alex Bennée
2019-09-26 16:11 ` Alistair Francis
2019-09-26 19:02 ` Alex Bennée
2019-09-27 8:55 ` Gerd Hoffmann
2019-09-26 15:31 ` Alex Bennée
2019-09-26 17:11 ` Richard Henderson
2019-09-30 9:25 ` Daniel P. Berrangé [this message]
[not found] ` <87impakrky.fsf@linaro.org>
2019-09-30 10:36 ` Peter Maydell
2019-09-30 11:41 ` Peter Maydell
2019-10-01 17:56 ` Mark Cave-Ayland
2019-10-01 18:02 ` Richard Henderson
2019-10-02 9:10 ` Daniel P. Berrangé
2019-10-02 15:16 ` Richard Henderson
2019-09-26 7:55 ` Thomas Huth
2019-09-26 15:27 ` Alex Bennée
2019-09-27 10:42 ` Mark Cave-Ayland
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=20190930092519.GB11996@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-discuss@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).