From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: qemu-arm@nongnu.org, Peter Maydell <peter.maydell@linaro.org>,
Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>,
qemu-devel@nongnu.org
Subject: Re: [PATCH] aspeed: Introduce helper for 32-bit hosts limitation
Date: Mon, 03 Jul 2023 14:47:17 +0100 [thread overview]
Message-ID: <878rbxhzp0.fsf@linaro.org> (raw)
In-Reply-To: <20230703124746.2456684-1-clg@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> On 32-bit hosts, RAM has a 2047 MB limit. Use a macro to define the
> default ram size of machines (AST2600 SoC) that can have 2 GB.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> hw/arm/aspeed.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 6880998484cd..9fca644d920e 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -47,6 +47,13 @@ struct AspeedMachineState {
> char *spi_model;
> };
>
> +/* On 32-bit hosts, lower RAM to 1G because of the 2047 MB limit */
> +#if HOST_LONG_BITS == 32
> +#define ASPEED_RAM_SIZE(sz) MIN((sz), 1 * GiB)
> +#else
> +#define ASPEED_RAM_SIZE(sz) (sz)
> +#endif
> +
On the one hand this seems a bit hacky to change the guest definition
based on the host architecture - to revive an ongoing argument about
64-on-32 configurations this seems an even more obvious subset of the
problem because regardless of the hoop jumping we do in code generation
we are limited in how much ram we can allocate.
On the other hand at least this moves the hackiness to one place:
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
prev parent reply other threads:[~2023-07-03 13:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-03 12:47 [PATCH] aspeed: Introduce helper for 32-bit hosts limitation Cédric Le Goater
2023-07-03 13:14 ` Philippe Mathieu-Daudé
2023-07-03 13:47 ` Alex Bennée [this message]
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=878rbxhzp0.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=andrew@aj.id.au \
--cc=clg@kaod.org \
--cc=joel@jms.id.au \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.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 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).