From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: Thomas Huth <thuth@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
Peter Maydell <peter.maydell@linaro.org>,
Joel Stanley <joel@jms.id.au>
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
"Samuel Thibault" <samuel.thibault@ens-lyon.org>,
"Andrew Jeffery" <andrew@aj.id.au>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"Cédric Le Goater" <clg@kaod.org>,
"Peter Delevoryas" <pdel@fb.com>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type)
Date: Wed, 15 Sep 2021 09:54:09 +0200 [thread overview]
Message-ID: <5dca12d8-8f8c-2c5e-3913-fd0627fdd7df@amsat.org> (raw)
In-Reply-To: <ee5d379f-a792-aae1-370a-b5f21582ae58@redhat.com>
On 9/15/21 9:42 AM, Thomas Huth wrote:
> On 14/09/2021 17.22, Richard Henderson wrote:
>> On 9/14/21 5:26 AM, Peter Maydell wrote:
>>> (2) RAM blocks should have a length that fits inside a
>>> signed 32-bit type on 32-bit hosts (at least I assume this
>>> is where the 2047MB limit is coming from; in theory this ought
>>> to be improveable but auditing the code for mishandling of
>>> RAMblock sizes to ensure we weren't accidentally stuffing
>>> their size into a signed 'long' somewhere would be kind
>>> of painful)
>>
>> Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit
>> while pointers are 64-bit, how close do we think we are to this being
>> fixed already?
>>
>>> Even if we did fix (2) we'd need to compromise on (3)
>>> sometimes still -- if a board has 4GB of RAM that's
>>> not going to fit in 32 bits regardless. But we would be
>>> able to let boards with 2GB have 2GB.
>>
>> I'm not opposed to deprecating 32-bit hosts... ;-)
>
> I think we should consider this again, indeed. Plain 32-bit CPUs are
> quite seldom these days, aren't they? And I think we urgently need to
> decrease the amount of things that we have to test and maintain in our
> CI and developer branches... So is there still a really really
> compelling reason to keep 32-bit host support alive?
> Could we maybe also decrease the amount of targets, i.e. merge
> qemu-system-x86_64 and qemu-system-i386, merge qemu-system-ppc64 and
> qemu-system-ppc, etc. where it makes sense (i.e. where one of the
> binaries is a superset of the other)?
Not directly related, but orthogonal to this, now than Richard got his
memory API series addressing endian issues merged, I'm slowly (in my
free time) trying to unify dual-endian machines. For user-emulation
it is a bit tricker so I'll look at it once sysemu is working. This
won't reduce the testing time, but the build time.
next prev parent reply other threads:[~2021-09-15 7:55 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-13 16:12 [PULL 00/14] aspeed queue Cédric Le Goater
2021-09-13 16:12 ` [PULL 01/14] hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evb Cédric Le Goater
2021-09-13 16:12 ` [PULL 02/14] hw: arm: aspeed: Enable mac0/1 instead of mac1/2 for g220a Cédric Le Goater
2021-09-13 16:12 ` [PULL 03/14] watchdog: aspeed: Sanitize control register values Cédric Le Goater
2021-09-13 16:12 ` [PULL 04/14] watchdog: aspeed: Fix sequential control writes Cédric Le Goater
2021-09-13 16:12 ` [PULL 05/14] hw: aspeed_gpio: Simplify 1.8V defines Cédric Le Goater
2021-09-13 16:12 ` [PULL 06/14] hw: aspeed_gpio: Clarify GPIO controller name Cédric Le Goater
2021-09-13 16:12 ` [PULL 07/14] misc/pca9552: Fix LED status register indexing in pca955x_get_led() Cédric Le Goater
2021-09-13 16:12 ` [PULL 08/14] arm/aspeed: rainier: Add i2c eeproms and muxes Cédric Le Goater
2021-09-13 16:12 ` [PULL 09/14] aspeed: Emulate the AST2600A3 Cédric Le Goater
2021-09-13 16:13 ` [PULL 10/14] hw/misc: Add Infineon DPS310 sensor model Cédric Le Goater
2021-09-13 16:13 ` [PULL 11/14] arm/aspeed: Add DPS310 to Witherspoon and Rainier Cédric Le Goater
2021-09-13 16:13 ` [PULL 12/14] hw/arm/aspeed: Initialize AST2600 UART clock selection registers Cédric Le Goater
2021-09-13 16:13 ` [PULL 13/14] hw/arm/aspeed: Allow machine to set UART default Cédric Le Goater
2021-09-13 16:13 ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
2021-09-14 10:56 ` Cédric Le Goater
2021-09-14 11:59 ` Peter Delevoryas
2021-09-14 12:14 ` Joel Stanley
2021-09-14 12:26 ` Peter Maydell
2021-09-14 15:22 ` Richard Henderson
2021-09-15 7:42 ` Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type) Thomas Huth
2021-09-15 7:54 ` Philippe Mathieu-Daudé [this message]
2021-09-15 8:37 ` Daniel P. Berrangé
2021-09-15 8:51 ` Philippe Mathieu-Daudé
2021-09-15 9:05 ` Daniel P. Berrangé
2021-09-16 12:29 ` [PULL 14/14] hw/arm/aspeed: Add Fuji machine type Cédric Le Goater
2021-09-16 13:53 ` Philippe Mathieu-Daudé
2021-09-16 14:06 ` Cédric Le Goater
2021-09-16 14:07 ` Peter Maydell
2021-09-14 10:51 ` [PULL 00/14] aspeed queue Peter Maydell
2021-09-14 10:58 ` Cédric Le Goater
2021-09-14 11:38 ` Philippe Mathieu-Daudé
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=5dca12d8-8f8c-2c5e-3913-fd0627fdd7df@amsat.org \
--to=f4bug@amsat.org \
--cc=andrew@aj.id.au \
--cc=berrange@redhat.com \
--cc=clg@kaod.org \
--cc=joel@jms.id.au \
--cc=pbonzini@redhat.com \
--cc=pdel@fb.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=thuth@redhat.com \
/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.