docs/about/deprecated.rst | 16 ++++++++++++++++ include/hw/core/cpu.h | 10 ++++++++++ target/i386/cpu.h | 4 ++-- cpu.c | 13 +++++++++++++ softmmu/vl.c | 1 + target/i386/cpu.c | 28 +++++++++++++--------------- target/i386/gdbstub.c | 8 +------- 7 files changed, 56 insertions(+), 24 deletions(-)
Allow running qemu-system-x86_64 in 32-bit-only mode (by renaming or symlinking the binary to "qemu-system-i386"). After doing this, qemu-system-x86_64 should be a proper superset of qemu-system-i386 (apart from 32-bit KVM support, which however is not really required anymore, see https://lore.kernel.org/kvm/Y%2ffkTs5ajFy0hP1U@google.com/ ). Thus we can finally deprecate the qemu-system-i386 binary. This will help to avoid that we have to compile a lot of the x86 stuff twice once we'll finally be able to drop qemu-system-i386. Marked as RFC since there are likely still a bunch of spots around that need attention, e.g.: - CPU types have different suffixes between the -x86_64 and -i386 variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care about this in the new qemu-system-i386 symlink run mode? - The code in target/i386/tcg/sysemu/smm_helper.c looks like it maybe needs a runtime switch, too ... or is it ok to leave this hard-coded to the x86_64 version? Anyway, I'd like to get some feedback on this idea here... What do you think of the idea of getting rid of the qemu-system-i386 binary this way in the future? Thomas Huth (3): cpu: Add a way to detect 32-bit mode from argv0 target/i386/cpu: Allow to limit the 64-bit binary to 32-bit mode only docs/about/deprecated: Deprecate the qemu-system-i386 binary docs/about/deprecated.rst | 16 ++++++++++++++++ include/hw/core/cpu.h | 10 ++++++++++ target/i386/cpu.h | 4 ++-- cpu.c | 13 +++++++++++++ softmmu/vl.c | 1 + target/i386/cpu.c | 28 +++++++++++++--------------- target/i386/gdbstub.c | 8 +------- 7 files changed, 56 insertions(+), 24 deletions(-) -- 2.31.1
On 4/25/23 15:38, Thomas Huth wrote: > - CPU types have different suffixes between the -x86_64 and -i386 > variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care > about this in the new qemu-system-i386 symlink run mode? > > - The code in target/i386/tcg/sysemu/smm_helper.c looks like it > maybe needs a runtime switch, too ... or is it ok to leave this > hard-coded to the x86_64 version? Yes, it would have to switch based on the CPU's LM feature. > Anyway, I'd like to get some feedback on this idea here... What > do you think of the idea of getting rid of the qemu-system-i386 > binary this way in the future? I wonder if we should take this a step further and rename qemu-system-x86_64 to qemu-system-x86! Distros can if they wish create symlinks to both qemu-system-i386 and qemu-system-x86_64. Then we would name the CPUs "foo-x86" and alias them to foo-x86_64 and, if they don't have LM set, to foo-i386 as well. Paolo
On Wed, Apr 26, 2023 at 12:59:13PM +0200, Paolo Bonzini wrote: > On 4/25/23 15:38, Thomas Huth wrote: > > - CPU types have different suffixes between the -x86_64 and -i386 > > variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care > > about this in the new qemu-system-i386 symlink run mode? > > > > - The code in target/i386/tcg/sysemu/smm_helper.c looks like it > > maybe needs a runtime switch, too ... or is it ok to leave this > > hard-coded to the x86_64 version? > > Yes, it would have to switch based on the CPU's LM feature. > > > Anyway, I'd like to get some feedback on this idea here... What > > do you think of the idea of getting rid of the qemu-system-i386 > > binary this way in the future? > > I wonder if we should take this a step further and rename qemu-system-x86_64 > to qemu-system-x86! Distros can if they wish create symlinks to both > qemu-system-i386 and qemu-system-x86_64. I can't help feeling this just creates a new upgrade burden for distros for no obvious win. Things have gone quite recently, but if we introduce next-generation QEMU system emulator binary which is 100% QMP based, I think that would be the ideal time to change naming convention to -x86 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 :|
On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > I wonder if we should take this a step further and rename qemu-system-x86_64 > > to qemu-system-x86! Distros can if they wish create symlinks to both > > qemu-system-i386 and qemu-system-x86_64. > > I can't help feeling this just creates a new upgrade burden for distros > for no obvious win. We can create the symlinks on install as well during the deprecation period. It doesn't have to be done by distros. For me, the main benefit of implementing -x86 for system emulation is that we need to move user-mode emulation to the x86_64 backend anyway. And the less difference between the two emulation scenarios, the better. Paolo > Things have gone quite recently, but if we introduce next-generation > QEMU system emulator binary which is 100% QMP based, I think that would > be the ideal time to change naming convention to -x86 > > 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 :| >
On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote: > On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > > I wonder if we should take this a step further and rename qemu-system-x86_64 > > > to qemu-system-x86! Distros can if they wish create symlinks to both > > > qemu-system-i386 and qemu-system-x86_64. > > > > I can't help feeling this just creates a new upgrade burden for distros > > for no obvious win. > > We can create the symlinks on install as well during the deprecation > period. It doesn't have to be done by distros. What's the actual win though ? Why would anyone want to create guests using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64 still exist indefinitely for backwards compat. What does having a qemu-system-x86 add that can't be achieve just though hardlink between the two existing binaries ? 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 :|
On 27/04/2023 10.33, Daniel P. Berrangé wrote: > On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote: >> On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote: >>>> I wonder if we should take this a step further and rename qemu-system-x86_64 >>>> to qemu-system-x86! Distros can if they wish create symlinks to both >>>> qemu-system-i386 and qemu-system-x86_64. >>> >>> I can't help feeling this just creates a new upgrade burden for distros >>> for no obvious win. >> >> We can create the symlinks on install as well during the deprecation >> period. It doesn't have to be done by distros. > > What's the actual win though ? Why would anyone want to create guests > using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64 > still exist indefinitely for backwards compat. We could deprecate the old wrappers at one point in time, so we would finally have a cleaner interface. > What does having a > qemu-system-x86 add that can't be achieve just though hardlink > between the two existing binaries ? We'd finally have a binary with saner default settings compared to the backlevel "pc" machine type that we have as a default now? Thomas
On Thu, Apr 27, 2023 at 02:12:59PM +0200, Thomas Huth wrote: > On 27/04/2023 10.33, Daniel P. Berrangé wrote: > > On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote: > > > On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > > I wonder if we should take this a step further and rename qemu-system-x86_64 > > > > > to qemu-system-x86! Distros can if they wish create symlinks to both > > > > > qemu-system-i386 and qemu-system-x86_64. > > > > > > > > I can't help feeling this just creates a new upgrade burden for distros > > > > for no obvious win. > > > > > > We can create the symlinks on install as well during the deprecation > > > period. It doesn't have to be done by distros. > > > > What's the actual win though ? Why would anyone want to create guests > > using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64 > > still exist indefinitely for backwards compat. > > We could deprecate the old wrappers at one point in time, so we would > finally have a cleaner interface. At the cost of breaking compat every single script and doc that referrs to the historical binaries. I think incompatible changes are worth it, but only if we associate them with the a approach to qemu system emulator binaries, as that's where we'll get a compelling benefit. Fiddling around with the existing binaries is creating pain for little gain IMHO. > > What does having a > > qemu-system-x86 add that can't be achieve just though hardlink > > between the two existing binaries ? > > We'd finally have a binary with saner default settings compared to the > backlevel "pc" machine type that we have as a default now? On the libvirt side we would have to ensure there was no change in defaults regardles of what he QEMU binary did. 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 :|
On 4/27/23 10:33, Daniel P. Berrangé wrote:
> On Thu, Apr 27, 2023 at 10:31:00AM +0200, Paolo Bonzini wrote:
>> On Thu, Apr 27, 2023 at 10:28 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>> I wonder if we should take this a step further and rename qemu-system-x86_64
>>>> to qemu-system-x86! Distros can if they wish create symlinks to both
>>>> qemu-system-i386 and qemu-system-x86_64.
>>>
>>> I can't help feeling this just creates a new upgrade burden for distros
>>> for no obvious win.
>>
>> We can create the symlinks on install as well during the deprecation
>> period. It doesn't have to be done by distros.
>
> What's the actual win though ? Why would anyone want to create guests
> using qemu-system-x86, if both qemu-system-i386 / qemu-system-x86_64
> still exist indefinitely for backwards compat. What does having a
> qemu-system-x86 add that can't be achieve just though hardlink
> between the two existing binaries ?
That the two existing binaries can also be removed sooner or later.
Even if we add a QMP-only binary, qemu-system-* would be a nicer
interface for developers and for quick-and-dirty launch of guests
(including usecases such as kvm-unit-tests). Libvirt is not even
available on Windows and I think on any non-Linux system? So having a
qemu-system-x86 that has the same defaults as qemu-qmp-x86 is useful for
developers.
That said, most people are really using qemu-kvm and not
qemu-system-{i386,x86_64}. On one hand it'd be nice if qemu-kvm's
default machine type changed away from "-M pc", on the other hand that
would have consequences on CLI backwards-compatibility. :(
Paolo
On 26/04/2023 12.59, Paolo Bonzini wrote: > On 4/25/23 15:38, Thomas Huth wrote: >> - CPU types have different suffixes between the -x86_64 and -i386 >> variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care >> about this in the new qemu-system-i386 symlink run mode? >> >> - The code in target/i386/tcg/sysemu/smm_helper.c looks like it >> maybe needs a runtime switch, too ... or is it ok to leave this >> hard-coded to the x86_64 version? > > Yes, it would have to switch based on the CPU's LM feature. Ok. BTW, what happens if you run qemu-system-x86_64 with -cpu lm=off today? Isn't that a problem already? >> Anyway, I'd like to get some feedback on this idea here... What >> do you think of the idea of getting rid of the qemu-system-i386 >> binary this way in the future? > > I wonder if we should take this a step further and rename qemu-system-x86_64 > to qemu-system-x86! Distros can if they wish create symlinks to both > qemu-system-i386 and qemu-system-x86_64. > > Then we would name the CPUs "foo-x86" and alias them to foo-x86_64 and, if > they don't have LM set, to foo-i386 as well. I like the idea! ... we could maybe even go a step further and change the default machine to "q35" in the -x86 binary (or use no default machine at all), and switch back to "pc" as default if running in -x86_64 or -i386 mode... Thomas
On 4/27/23 10:13, Thomas Huth wrote: > On 26/04/2023 12.59, Paolo Bonzini wrote: >> On 4/25/23 15:38, Thomas Huth wrote: >>> - CPU types have different suffixes between the -x86_64 and -i386 >>> variant (see TYPE_X86_CPU in cpu-qom.h) ... do we need to care >>> about this in the new qemu-system-i386 symlink run mode? >>> >>> - The code in target/i386/tcg/sysemu/smm_helper.c looks like it >>> maybe needs a runtime switch, too ... or is it ok to leave this >>> hard-coded to the x86_64 version? >> >> Yes, it would have to switch based on the CPU's LM feature. > > Ok. BTW, what happens if you run qemu-system-x86_64 with -cpu lm=off > today? Isn't that a problem already? Nothing special---I was thinking of migration compatibility from old savefiles created with qemu-system-i386, but using LM would break compatibility from old savefiles created with qemu-system-x86_64 and 32-bit CPU models. A better way to go would be to have a separate property than LM (e.g. 64bit-smm-format=on|off), and add a "-global" based on -i386 vs. -x86_64. >>> Anyway, I'd like to get some feedback on this idea here... What >>> do you think of the idea of getting rid of the qemu-system-i386 >>> binary this way in the future? >> >> I wonder if we should take this a step further and rename >> qemu-system-x86_64 to qemu-system-x86! Distros can if they wish >> create symlinks to both qemu-system-i386 and qemu-system-x86_64. >> >> Then we would name the CPUs "foo-x86" and alias them to foo-x86_64 >> and, if they don't have LM set, to foo-i386 as well. > > I like the idea! ... we could maybe even go a step further and change > the default machine to "q35" in the -x86 binary (or use no default > machine at all), and switch back to "pc" as default if running in > -x86_64 or -i386 mode... That's a clever way to move away from the "-M pc" default, indeed. (BTW, on the user-mode emulation side qemu-i386 and qemu-x86_64 identify the ABI, so the binaries cannot be unified. Still, it would be beneficial to make qemu-i386 use the x86_64 emulation code, because right now QEMU user-mode emulation---unlike real hardware---cannot run 32-bit binaries with new CPU models. So the above unification effort would benefit both system and user-mode emulators). Paolo
© 2016 - 2024 Red Hat, Inc.