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.

Lets mark these machines as deprecated so we can have the wailing and
gnashing of teeth now and look to actually dropping the support in a
couple of cycles.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Richard Henderson <richard.henderson@linaro.org>
---
 configure | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/configure b/configure
index 542f6aea3f..776fd460b5 100755
--- a/configure
+++ b/configure
@@ -728,7 +728,7 @@ ARCH=
 # Normalise host CPU name and set ARCH.
 # Note that this case should only have supported host CPUs, not guests.
 case "$cpu" in
-  ppc|ppc64|s390|s390x|sparc64|x32|riscv32|riscv64)
+  ppc64|s390|s390x|sparc64|riscv64)
     supported_cpu="yes"
   ;;
   ppc64le)
@@ -737,7 +737,6 @@ case "$cpu" in
   ;;
   i386|i486|i586|i686|i86pc|BePC)
     cpu="i386"
-    supported_cpu="yes"
   ;;
   x86_64|amd64)
     cpu="x86_64"
@@ -745,19 +744,22 @@ case "$cpu" in
   ;;
   armv*b|armv*l|arm)
     cpu="arm"
-    supported_cpu="yes"
   ;;
   aarch64)
     cpu="aarch64"
     supported_cpu="yes"
   ;;
-  mips*)
+  mips64*)
     cpu="mips"
     supported_cpu="yes"
   ;;
+  mips*)
+    cpu="mips"
+  ;;
   sparc|sun4[cdmuv])
     cpu="sparc"
-    supported_cpu="yes"
+  ;;
+  x32|riscv32)
   ;;
   *)
     # This will result in either an error or falling back to TCI later
@@ -6438,12 +6440,12 @@ if test "$supported_cpu" = "no"; then
     echo "WARNING: SUPPORT FOR THIS HOST CPU WILL GO AWAY IN FUTURE RELEASES!"
     echo
     echo "CPU host architecture $cpu support is not currently maintained."
-    echo "The QEMU project intends to remove support for this host CPU in"
-    echo "a future release if nobody volunteers to maintain it and to"
-    echo "provide a build host for our continuous integration setup."
-    echo "configure has succeeded and you can continue to build, but"
-    echo "if you care about QEMU on this platform you should contact"
-    echo "us upstream at qemu-devel@nongnu.org."
+    echo "The QEMU project intends to remove support for all 32 bit host"
+    echo "CPUs in a future release. 64 bit hosts will need a volunteer"
+    echo "to maintain it and to provide a build host for our continuous"
+    echo "integration setup. configure has succeeded and you can continue"
+    echo "to build, but if you care about QEMU on this platform you"
+    echo "should contact us upstream at qemu-devel@nongnu.org."
 fi
 
 if test "$supported_os" = "no"; then
-- 
2.20.1

On 9/26/19 1:30 AM, Alex Bennée 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.
> 
> Lets mark these machines as deprecated so we can have the wailing and
> gnashing of teeth now and look to actually dropping the support in a
> couple of cycles.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> ---
>  configure | 24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/configure b/configure
> index 542f6aea3f..776fd460b5 100755
> --- a/configure
> +++ b/configure
> @@ -728,7 +728,7 @@ ARCH=
>  # Normalise host CPU name and set ARCH.
>  # Note that this case should only have supported host CPUs, not guests.
>  case "$cpu" in
> -  ppc|ppc64|s390|s390x|sparc64|x32|riscv32|riscv64)
> +  ppc64|s390|s390x|sparc64|riscv64)
>      supported_cpu="yes"
>    ;;
>    ppc64le)
> @@ -737,7 +737,6 @@ case "$cpu" in
>    ;;
>    i386|i486|i586|i686|i86pc|BePC)
>      cpu="i386"
> -    supported_cpu="yes"
>    ;;
>    x86_64|amd64)
>      cpu="x86_64"
> @@ -745,19 +744,22 @@ case "$cpu" in
>    ;;
>    armv*b|armv*l|arm)
>      cpu="arm"
> -    supported_cpu="yes"

I think linux-user is quite used in embedded stuff such NAS.

Eventually this public don't need edge QEMU, it might keep using QEMU
v5.0.stable until all NAS/embedded devices are 64-bit...

>    ;;
>    aarch64)
>      cpu="aarch64"
>      supported_cpu="yes"
>    ;;
> -  mips*)
> +  mips64*)
>      cpu="mips"
>      supported_cpu="yes"
>    ;;
> +  mips*)
> +    cpu="mips"

Similarly I can imagine linux-user being used on some routers.

> +  ;;
>    sparc|sun4[cdmuv])
>      cpu="sparc"
> -    supported_cpu="yes"
> +  ;;
> +  x32|riscv32)

x32 is borderline :) but yes, pointers are 32-bit.

>    ;;
>    *)
>      # This will result in either an error or falling back to TCI later
> @@ -6438,12 +6440,12 @@ if test "$supported_cpu" = "no"; then
>      echo "WARNING: SUPPORT FOR THIS HOST CPU WILL GO AWAY IN FUTURE RELEASES!"
>      echo
>      echo "CPU host architecture $cpu support is not currently maintained."
> -    echo "The QEMU project intends to remove support for this host CPU in"
> -    echo "a future release if nobody volunteers to maintain it and to"
> -    echo "provide a build host for our continuous integration setup."
> -    echo "configure has succeeded and you can continue to build, but"
> -    echo "if you care about QEMU on this platform you should contact"
> -    echo "us upstream at qemu-devel@nongnu.org."
> +    echo "The QEMU project intends to remove support for all 32 bit host"
> +    echo "CPUs in a future release. 64 bit hosts will need a volunteer"
> +    echo "to maintain it and to provide a build host for our continuous"
> +    echo "integration setup. configure has succeeded and you can continue"
> +    echo "to build, but if you care about QEMU on this platform you"
> +    echo "should contact us upstream at qemu-devel@nongnu.org."
>  fi
>  
>  if test "$supported_os" = "no"; then
> 

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.

> @@ -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).


thanks
-- PMM

Peter Maydell <peter.maydell@linaro.org> writes:

> 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.

I can certainly do that - although I'd still like to know who actually
uses 32 bit kvm support these days.

>
>> @@ -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).

raspi is probably the most common one because of the 32 bit userspace
they use even though they are running on 64 bit chips.

>
>
> thanks
> -- PMM


--
Alex Bennée

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.

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~

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 :|

On Thu, Sep 26, 2019 at 08:50:36AM +0100, 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.

What if the kernel is waiting for QEMU to drop support too ;-P

> > @@ -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).

RHEL dropped all 32-bit host support a long time ago, so Red Hat
don't care for our products.

Fedora has recently stopped building i686 kernels and thus also no
long composes i686 installs. Some users complained, but ultimately
no one cares enough to step forward as maintainers.

That leaves armv7 as the only 32-bit arch in Fedora that is somewhat
active & maintained. I don't have any real insight on whether any
armv7 (Fedora) users are making much use of QEMU/KVM though, either
system or user emulation. 

Our preference in Fedora is to have things built on every architecture
that the distro targets, but if upstream developers explicitly drop an
architecture we're not going to try to add it back.

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 :|

  Hi,

> That leaves armv7 as the only 32-bit arch in Fedora that is somewhat
> active & maintained. I don't have any real insight on whether any
> armv7 (Fedora) users are making much use of QEMU/KVM though, either
> system or user emulation. 

Played with system emulation a while back.  I doubt this is used much
in practice.  It's very slow for various reasons (no gic, no armv8 arch
updates to support kvm virt better, slow sdcard/usb I/O).  TCG on a
beefy x86 box is roughly the same speed.  Also 1G of memory isn't that
much even without considering virtual machines.

The rpi4 with 4G (disclaimer: don't have one) probably works better.
But note they are finally working on a 64bit kernel for raspbian,
which I expect is only a first step for better 64bit support.

cheers,
  Gerd

On 26.09.19 14:58, Daniel P. Berrangé wrote:
> On Thu, Sep 26, 2019 at 08:50:36AM +0100, 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.
> 
> What if the kernel is waiting for QEMU to drop support too ;-P

For what its worth on kvm/s390 we never cared about implementing
32 bit. 

> 
>>> @@ -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).
> 
> RHEL dropped all 32-bit host support a long time ago, so Red Hat
> don't care for our products.
> 
> Fedora has recently stopped building i686 kernels and thus also no
> long composes i686 installs. Some users complained, but ultimately
> no one cares enough to step forward as maintainers.
> 
> That leaves armv7 as the only 32-bit arch in Fedora that is somewhat
> active & maintained. I don't have any real insight on whether any
> armv7 (Fedora) users are making much use of QEMU/KVM though, either
> system or user emulation. 
> 
> Our preference in Fedora is to have things built on every architecture
> that the distro targets, but if upstream developers explicitly drop an
> architecture we're not going to try to add it back.
> 
> Regards,
> Daniel
> 

On 26/09/2019 15.46, Christian Borntraeger wrote:
> 
> 
> On 26.09.19 14:58, Daniel P. Berrangé wrote:
>> On Thu, Sep 26, 2019 at 08:50:36AM +0100, 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.
>>
>> What if the kernel is waiting for QEMU to drop support too ;-P
> 
> For what its worth on kvm/s390 we never cared about implementing
> 32 bit. 

Looking at tcg/s390/tcg-target.inc.c :

...
/* We only support generating code for 64-bit mode.  */
#if TCG_TARGET_REG_BITS != 64
#error "unsupported code generation mode"
#endif
...

... it seems to me that TCG does not support 32-bit on s390 either. I
think we can remove s390 (32-bit) from the list completely?

 Thomas

Thomas Huth <thuth@redhat.com> writes:

> On 26/09/2019 15.46, Christian Borntraeger wrote:
>>
>>
>> On 26.09.19 14:58, Daniel P. Berrangé wrote:
>>> On Thu, Sep 26, 2019 at 08:50:36AM +0100, 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.
>>>
>>> What if the kernel is waiting for QEMU to drop support too ;-P
>>
>> For what its worth on kvm/s390 we never cared about implementing
>> 32 bit.
>
> Looking at tcg/s390/tcg-target.inc.c :
>
> ...
> /* We only support generating code for 64-bit mode.  */
> #if TCG_TARGET_REG_BITS != 64
> #error "unsupported code generation mode"
> #endif
> ...
>
> ... it seems to me that TCG does not support 32-bit on s390 either. I
> think we can remove s390 (32-bit) from the list completely?

It's the same for riscv32 I think.

>
>  Thomas


--
Alex Bennée

On Thu, Sep 26, 2019 at 8:41 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Thomas Huth <thuth@redhat.com> writes:
>
> > On 26/09/2019 15.46, Christian Borntraeger wrote:
> >>
> >>
> >> On 26.09.19 14:58, Daniel P. Berrangé wrote:
> >>> On Thu, Sep 26, 2019 at 08:50:36AM +0100, 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.
> >>>
> >>> What if the kernel is waiting for QEMU to drop support too ;-P
> >>
> >> For what its worth on kvm/s390 we never cared about implementing
> >> 32 bit.
> >
> > Looking at tcg/s390/tcg-target.inc.c :
> >
> > ...
> > /* We only support generating code for 64-bit mode.  */
> > #if TCG_TARGET_REG_BITS != 64
> > #error "unsupported code generation mode"
> > #endif
> > ...
> >
> > ... it seems to me that TCG does not support 32-bit on s390 either. I
> > think we can remove s390 (32-bit) from the list completely?
>
> It's the same for riscv32 I think.

I think riscv32 host *should* work, although I don't think it was ever tested.

Considering that we have enough trouble keeping the riscv32 kernel
booting it's probably ok to drop it from QEMU.

Alistair

>
> >
> >  Thomas
>
>
> --
> Alex Bennée
>

Alistair Francis <alistair23@gmail.com> writes:

> On Thu, Sep 26, 2019 at 8:41 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Thomas Huth <thuth@redhat.com> writes:
>>
>> > On 26/09/2019 15.46, Christian Borntraeger wrote:
>> >>
>> >>
>> >> On 26.09.19 14:58, Daniel P. Berrangé wrote:
>> >>> On Thu, Sep 26, 2019 at 08:50:36AM +0100, 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.
>> >>>
>> >>> What if the kernel is waiting for QEMU to drop support too ;-P
>> >>
>> >> For what its worth on kvm/s390 we never cared about implementing
>> >> 32 bit.
>> >
>> > Looking at tcg/s390/tcg-target.inc.c :
>> >
>> > ...
>> > /* We only support generating code for 64-bit mode.  */
>> > #if TCG_TARGET_REG_BITS != 64
>> > #error "unsupported code generation mode"
>> > #endif
>> > ...
>> >
>> > ... it seems to me that TCG does not support 32-bit on s390 either. I
>> > think we can remove s390 (32-bit) from the list completely?
>>
>> It's the same for riscv32 I think.
>
> I think riscv32 host *should* work, although I don't think it was ever
> tested.

You certainly don't support oversized guests:

  /* We don't support oversize guests */
  QEMU_BUILD_BUG_ON(TCG_TARGET_REG_BITS < TARGET_LONG_BITS);

>
> Considering that we have enough trouble keeping the riscv32 kernel
> booting it's probably ok to drop it from QEMU.
>
> Alistair
>
>>
>> >
>> >  Thomas
>>
>>
>> --
>> Alex Bennée
>>


--
Alex Bennée

On 26/09/2019 01.30, Alex Bennée 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.
> 
> Lets mark these machines as deprecated so we can have the wailing and
> gnashing of teeth now and look to actually dropping the support in a
> couple of cycles.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> ---
>  configure | 24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/configure b/configure
> index 542f6aea3f..776fd460b5 100755
> --- a/configure
> +++ b/configure
> @@ -728,7 +728,7 @@ ARCH=
>  # Normalise host CPU name and set ARCH.
>  # Note that this case should only have supported host CPUs, not guests.
>  case "$cpu" in
> -  ppc|ppc64|s390|s390x|sparc64|x32|riscv32|riscv64)
> +  ppc64|s390|s390x|sparc64|riscv64)

I think you can also remove "s390". "s390" is the 32-bit variant,
"s390x" is the 64-bit variant.

>      supported_cpu="yes"
>    ;;
>    ppc64le)
> @@ -737,7 +737,6 @@ case "$cpu" in
>    ;;
>    i386|i486|i586|i686|i86pc|BePC)
>      cpu="i386"
> -    supported_cpu="yes"
>    ;;
>    x86_64|amd64)
>      cpu="x86_64"
> @@ -745,19 +744,22 @@ case "$cpu" in
>    ;;
>    armv*b|armv*l|arm)
>      cpu="arm"
> -    supported_cpu="yes"
>    ;;
>    aarch64)
>      cpu="aarch64"
>      supported_cpu="yes"
>    ;;
> -  mips*)
> +  mips64*)
>      cpu="mips"
>      supported_cpu="yes"
>    ;;
> +  mips*)
> +    cpu="mips"
> +  ;;
>    sparc|sun4[cdmuv])
>      cpu="sparc"
> -    supported_cpu="yes"
> +  ;;
> +  x32|riscv32)

You forgot to add "ppc" (and "s390") here.

>    ;;
>    *)
>      # This will result in either an error or falling back to TCI later
> @@ -6438,12 +6440,12 @@ if test "$supported_cpu" = "no"; then
>      echo "WARNING: SUPPORT FOR THIS HOST CPU WILL GO AWAY IN FUTURE RELEASES!"
>      echo
>      echo "CPU host architecture $cpu support is not currently maintained."
> -    echo "The QEMU project intends to remove support for this host CPU in"
> -    echo "a future release if nobody volunteers to maintain it and to"
> -    echo "provide a build host for our continuous integration setup."
> -    echo "configure has succeeded and you can continue to build, but"
> -    echo "if you care about QEMU on this platform you should contact"
> -    echo "us upstream at qemu-devel@nongnu.org."
> +    echo "The QEMU project intends to remove support for all 32 bit host"
> +    echo "CPUs in a future release. 64 bit hosts will need a volunteer"
> +    echo "to maintain it and to provide a build host for our continuous"
> +    echo "integration setup. configure has succeeded and you can continue"
> +    echo "to build, but if you care about QEMU on this platform you"
> +    echo "should contact us upstream at qemu-devel@nongnu.org."
>  fi
>  
>  if test "$supported_os" = "no"; then

In case this gets accepted, we also might want to deprecate the
qemu-system-i386, qemu-system-arm and qemu-system-ppc targets, since
they are AFAIK just a subset of qemu-system-x86_64, qemu-system-aarch64
and qemu-system-ppc64. But that's likely something for a later patch, I
think.

 Thomas

Thomas Huth <thuth@redhat.com> writes:

> On 26/09/2019 01.30, Alex Bennée 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.
>>
>> Lets mark these machines as deprecated so we can have the wailing and
>> gnashing of teeth now and look to actually dropping the support in a
>> couple of cycles.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> Cc: Richard Henderson <richard.henderson@linaro.org>
>> ---
>>  configure | 24 +++++++++++++-----------
>>  1 file changed, 13 insertions(+), 11 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 542f6aea3f..776fd460b5 100755
>> --- a/configure
>> +++ b/configure
>> @@ -728,7 +728,7 @@ ARCH=
>>  # Normalise host CPU name and set ARCH.
>>  # Note that this case should only have supported host CPUs, not guests.
>>  case "$cpu" in
>> -  ppc|ppc64|s390|s390x|sparc64|x32|riscv32|riscv64)
>> +  ppc64|s390|s390x|sparc64|riscv64)
>
> I think you can also remove "s390". "s390" is the 32-bit variant,
> "s390x" is the 64-bit variant.
>
>>      supported_cpu="yes"
>>    ;;
>>    ppc64le)
>> @@ -737,7 +737,6 @@ case "$cpu" in
>>    ;;
>>    i386|i486|i586|i686|i86pc|BePC)
>>      cpu="i386"
>> -    supported_cpu="yes"
>>    ;;
>>    x86_64|amd64)
>>      cpu="x86_64"
>> @@ -745,19 +744,22 @@ case "$cpu" in
>>    ;;
>>    armv*b|armv*l|arm)
>>      cpu="arm"
>> -    supported_cpu="yes"
>>    ;;
>>    aarch64)
>>      cpu="aarch64"
>>      supported_cpu="yes"
>>    ;;
>> -  mips*)
>> +  mips64*)
>>      cpu="mips"
>>      supported_cpu="yes"
>>    ;;
>> +  mips*)
>> +    cpu="mips"
>> +  ;;
>>    sparc|sun4[cdmuv])
>>      cpu="sparc"
>> -    supported_cpu="yes"
>> +  ;;
>> +  x32|riscv32)
>
> You forgot to add "ppc" (and "s390") here.
>
>>    ;;
>>    *)
>>      # This will result in either an error or falling back to TCI later
>> @@ -6438,12 +6440,12 @@ if test "$supported_cpu" = "no"; then
>>      echo "WARNING: SUPPORT FOR THIS HOST CPU WILL GO AWAY IN FUTURE RELEASES!"
>>      echo
>>      echo "CPU host architecture $cpu support is not currently maintained."
>> -    echo "The QEMU project intends to remove support for this host CPU in"
>> -    echo "a future release if nobody volunteers to maintain it and to"
>> -    echo "provide a build host for our continuous integration setup."
>> -    echo "configure has succeeded and you can continue to build, but"
>> -    echo "if you care about QEMU on this platform you should contact"
>> -    echo "us upstream at qemu-devel@nongnu.org."
>> +    echo "The QEMU project intends to remove support for all 32 bit host"
>> +    echo "CPUs in a future release. 64 bit hosts will need a volunteer"
>> +    echo "to maintain it and to provide a build host for our continuous"
>> +    echo "integration setup. configure has succeeded and you can continue"
>> +    echo "to build, but if you care about QEMU on this platform you"
>> +    echo "should contact us upstream at qemu-devel@nongnu.org."
>>  fi
>>
>>  if test "$supported_os" = "no"; then
>
> In case this gets accepted, we also might want to deprecate the
> qemu-system-i386, qemu-system-arm and qemu-system-ppc targets, since
> they are AFAIK just a subset of qemu-system-x86_64, qemu-system-aarch64
> and qemu-system-ppc64. But that's likely something for a later patch, I
> think.

Yes this is purely for the host side. I'm not intending to deprecate any
guest support.

>
>  Thomas


--
Alex Bennée

On 26/09/2019 00:30, Alex Bennée 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.
> 
> Lets mark these machines as deprecated so we can have the wailing and
> gnashing of teeth now and look to actually dropping the support in a
> couple of cycles.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> ---
>  configure | 24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/configure b/configure
> index 542f6aea3f..776fd460b5 100755
> --- a/configure
> +++ b/configure
> @@ -728,7 +728,7 @@ ARCH=
>  # Normalise host CPU name and set ARCH.
>  # Note that this case should only have supported host CPUs, not guests.
>  case "$cpu" in
> -  ppc|ppc64|s390|s390x|sparc64|x32|riscv32|riscv64)
> +  ppc64|s390|s390x|sparc64|riscv64)
>      supported_cpu="yes"
>    ;;
>    ppc64le)
> @@ -737,7 +737,6 @@ case "$cpu" in
>    ;;
>    i386|i486|i586|i686|i86pc|BePC)
>      cpu="i386"
> -    supported_cpu="yes"
>    ;;
>    x86_64|amd64)
>      cpu="x86_64"
> @@ -745,19 +744,22 @@ case "$cpu" in
>    ;;
>    armv*b|armv*l|arm)
>      cpu="arm"
> -    supported_cpu="yes"
>    ;;
>    aarch64)
>      cpu="aarch64"
>      supported_cpu="yes"
>    ;;
> -  mips*)
> +  mips64*)
>      cpu="mips"
>      supported_cpu="yes"
>    ;;
> +  mips*)
> +    cpu="mips"
> +  ;;
>    sparc|sun4[cdmuv])
>      cpu="sparc"
> -    supported_cpu="yes"
> +  ;;
> +  x32|riscv32)
>    ;;
>    *)
>      # This will result in either an error or falling back to TCI later
> @@ -6438,12 +6440,12 @@ if test "$supported_cpu" = "no"; then
>      echo "WARNING: SUPPORT FOR THIS HOST CPU WILL GO AWAY IN FUTURE RELEASES!"
>      echo
>      echo "CPU host architecture $cpu support is not currently maintained."
> -    echo "The QEMU project intends to remove support for this host CPU in"
> -    echo "a future release if nobody volunteers to maintain it and to"
> -    echo "provide a build host for our continuous integration setup."
> -    echo "configure has succeeded and you can continue to build, but"
> -    echo "if you care about QEMU on this platform you should contact"
> -    echo "us upstream at qemu-devel@nongnu.org."
> +    echo "The QEMU project intends to remove support for all 32 bit host"
> +    echo "CPUs in a future release. 64 bit hosts will need a volunteer"
> +    echo "to maintain it and to provide a build host for our continuous"
> +    echo "integration setup. configure has succeeded and you can continue"
> +    echo "to build, but if you care about QEMU on this platform you"
> +    echo "should contact us upstream at qemu-devel@nongnu.org."
>  fi
>  
>  if test "$supported_os" = "no"; then

FWIW I still use my Mac Mini G4 (with KVM) to help debug bits of TCG for
qemu-system-ppc and so I would certainly miss this for bits of my Mac work.

Is it possible to reach a compromise based on host/target i.e. allow 32-bit hosts to
only run targets up to 32-bits? I'd only ever want to use qemu-system-ppc on the Mac
Mini for testing: for qemu-system-ppc64 it is clearly much quicker just to use the
nearest x86 box.


ATB,

Mark.