From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
qemu-arm@nongnu.org, "Maxim Levitsky" <mlevitsk@redhat.com>,
libvir-list@redhat.com,
"Richard Henderson" <richard.henderson@linaro.org>,
xen-devel@lists.xenproject.org,
"Reinoud Zandijk" <reinoud@netbsd.org>,
"Wilfred Mallawa" <wilfred.mallawa@wdc.com>,
"John Paul Adrian Glaubitz" <glaubitz@physik.fu-berlin.de>
Subject: Re: [PATCH v4 2/5] docs/about/deprecated: Deprecate the qemu-system-i386 binary
Date: Mon, 6 Mar 2023 09:27:01 +0000 [thread overview]
Message-ID: <ZAWx5eBskd1cItDx@redhat.com> (raw)
In-Reply-To: <20230306084658.29709-3-thuth@redhat.com>
On Mon, Mar 06, 2023 at 09:46:55AM +0100, Thomas Huth wrote:
> Aside from not supporting KVM on 32-bit hosts, the qemu-system-x86_64
> binary is a proper superset of the qemu-system-i386 binary. With the
> 32-bit host support being deprecated, it is now also possible to
> deprecate the qemu-system-i386 binary.
>
> With regards to 32-bit KVM support in the x86 Linux kernel,
> the developers confirmed that they do not need a recent
> qemu-system-i386 binary here:
>
> https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/
>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Reviewed-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> docs/about/deprecated.rst | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 1ca9dc33d6..c4fcc6b33c 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -34,6 +34,20 @@ deprecating the build option and no longer defend it in CI. The
> ``--enable-gcov`` build option remains for analysis test case
> coverage.
>
> +``qemu-system-i386`` binary (since 8.0)
> +'''''''''''''''''''''''''''''''''''''''
> +
> +The ``qemu-system-i386`` binary was mainly useful for running with KVM
> +on 32-bit x86 hosts, but most Linux distributions already removed their
> +support for 32-bit x86 kernels, so hardly anybody still needs this. The
> +``qemu-system-x86_64`` binary is a proper superset and can be used to
> +run 32-bit guests by selecting a 32-bit CPU model, including KVM support
> +on x86_64 hosts. Thus users are recommended to reconfigure their systems
> +to use the ``qemu-system-x86_64`` binary instead. If a 32-bit CPU guest
> +environment should be enforced, you can switch off the "long mode" CPU
> +flag, e.g. with ``-cpu max,lm=off``.
I had the idea to check this today and this is not quite sufficient,
because we have code that changes the family/model/stepping for
'max' which is target dependent:
#ifdef TARGET_X86_64
object_property_set_int(OBJECT(cpu), "family", 15, &error_abort);
object_property_set_int(OBJECT(cpu), "model", 107, &error_abort);
object_property_set_int(OBJECT(cpu), "stepping", 1, &error_abort);
#else
object_property_set_int(OBJECT(cpu), "family", 6, &error_abort);
object_property_set_int(OBJECT(cpu), "model", 6, &error_abort);
object_property_set_int(OBJECT(cpu), "stepping", 3, &error_abort);
#endif
The former is a 64-bit AMD model and the latter is a 32-bit model.
Seems LLVM was sensitive to this distinction to some extent:
https://gitlab.com/qemu-project/qemu/-/issues/191
A further difference is that qemy-system-i686 does not appear to enable
the 'syscall' flag, but I've not figured out where that difference is
coming from in the code.
With 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 :|
next prev parent reply other threads:[~2023-03-06 9:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 8:46 [PATCH v4 0/5] Deprecate system emulation support for 32-bit x86 and arm hosts Thomas Huth
2023-03-06 8:46 ` [PATCH v4 1/5] docs/about/deprecated: Deprecate 32-bit x86 hosts for system emulation Thomas Huth
2023-03-06 8:46 ` [PATCH v4 2/5] docs/about/deprecated: Deprecate the qemu-system-i386 binary Thomas Huth
2023-03-06 9:27 ` Daniel P. Berrangé [this message]
2023-03-06 9:54 ` Thomas Huth
2023-03-06 9:58 ` Daniel P. Berrangé
2023-03-06 13:48 ` Thomas Huth
2023-03-06 14:06 ` Daniel P. Berrangé
2023-03-06 14:18 ` Thomas Huth
2023-03-06 14:25 ` Daniel P. Berrangé
2023-03-06 14:58 ` Daniel P. Berrangé
2023-03-06 14:56 ` Philippe Mathieu-Daudé
2023-03-06 8:46 ` [PATCH v4 3/5] gitlab-ci.d/crossbuilds: Drop the i386 system emulation job Thomas Huth
2023-03-06 9:19 ` Philippe Mathieu-Daudé
2023-03-06 8:46 ` [PATCH v4 4/5] docs/about/deprecated: Deprecate 32-bit arm hosts for system emulation Thomas Huth
2023-03-06 9:23 ` Philippe Mathieu-Daudé
2023-03-07 2:43 ` Richard Henderson
2023-03-06 8:46 ` [PATCH v4 5/5] gitlab-ci.d/crossbuilds: Drop the 32-bit arm system emulation jobs Thomas Huth
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=ZAWx5eBskd1cItDx@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=libvir-list@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=reinoud@netbsd.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
--cc=wilfred.mallawa@wdc.com \
--cc=xen-devel@lists.xenproject.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 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.