| Message ID | 20190925233013.6449-1-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] configure: deprecate 32 bit build hosts | expand |
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
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
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 :|
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 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
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
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 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 >
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~
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
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/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.
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 Mon, 30 Sep 2019 at 11:26, Alex Bennée <alex.bennee@linaro.org> wrote: > So if lots of people still want 32 bit host support for TCG guests we > can probably come up with something that keeps existing functionality > ticking over while leaving the newer architectural features to 64 bit > hosts only. I don't think we should do that -- QEMU should offer the same (emulated) functionality regardless of host. thanks -- PMM
On Mon, 30 Sep 2019 at 11:26, Alex Bennée <alex.bennee@linaro.org> wrote: > The int128 support is due to the fact we are going to start to see newer > architectures with things like 128 bit shadow capability registers and > they will be a pain to shuffle around in 32 bit generated host code as > well as requiring writing new extra plumbing for TCG's pre/post amble to > pass them back and forth between C and generated code. These guest > architectures may not even be full 64 bit guests so it's not quite as > simple as saying you can't have 64 bit guests on a 32 bit host. I think that for int128_t in particular, the ideal answer is that if the compiler developers want to introduce a new abstraction like that, they should support it on all targets, not just half of them... thanks -- PMM
On 30/09/2019 12:41, Peter Maydell wrote: > On Mon, 30 Sep 2019 at 11:26, Alex Bennée <alex.bennee@linaro.org> wrote: >> The int128 support is due to the fact we are going to start to see newer >> architectures with things like 128 bit shadow capability registers and >> they will be a pain to shuffle around in 32 bit generated host code as >> well as requiring writing new extra plumbing for TCG's pre/post amble to >> pass them back and forth between C and generated code. These guest >> architectures may not even be full 64 bit guests so it's not quite as >> simple as saying you can't have 64 bit guests on a 32 bit host. > > I think that for int128_t in particular, the ideal answer is > that if the compiler developers want to introduce a new > abstraction like that, they should support it on all targets, > not just half of them... Just out of interest, which host/compiler combinations don't currently implement int128_t? ATB, Mark.
On 10/1/19 10:56 AM, Mark Cave-Ayland wrote: > Just out of interest, which host/compiler combinations don't currently implement > int128_t? GCC only implements int128_t for 64-bit targets. r~
On Tue, Oct 01, 2019 at 11:02:14AM -0700, Richard Henderson wrote: > On 10/1/19 10:56 AM, Mark Cave-Ayland wrote: > > Just out of interest, which host/compiler combinations don't currently implement > > int128_t? > > GCC only implements int128_t for 64-bit targets. QEMU probes for that during configure and sets CONFIG_INT128 If I'm reading correctly include/qemu/int128.h then provides a fallback type based on a struct with two int64s. This has some inconvenience though as you have to use the the (inline) function calls for all the basic operands and will be less efficient when using the fallback. Presumably this is not viable for TCG ? 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 10/2/19 2:10 AM, Daniel P. Berrangé wrote: >> GCC only implements int128_t for 64-bit targets. > > QEMU probes for that during configure and sets CONFIG_INT128 > > If I'm reading correctly include/qemu/int128.h then provides a > fallback type based on a struct with two int64s. > > This has some inconvenience though as you have to use the the (inline) > function calls for all the basic operands and will be less efficient > when using the fallback. > > Presumably this is not viable for TCG ? A structure (for some ABIs) may be passed and returned by invisible reference. It's not impossible (nothing's impossible), but it adds previously unnecessary complexity to allocate that storage on the jit stack. Actually manipulating one 128-bit value consumes 4/6 of the i386 registers, which I can well imagine could wind up causing problems. Certainly manipulating two values at once is out of the question. That's less of a problem for arm and mips. Anyway, all of the pain points go away if we assume 64-bit. r~
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
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(-) -- 2.20.1