qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] configure: deprecate 32 bit build hosts


From: Richard Henderson
Subject: Re: [RFC PATCH] configure: deprecate 32 bit build hosts
Date: Thu, 26 Sep 2019 10:11:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 9/26/19 12:50 AM, Peter Maydell wrote:
> On Thu, 26 Sep 2019 at 00:31, Alex Bennée <address@hidden> 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.

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.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]