[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Dropped CPU feature names and backward compatibility
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] Dropped CPU feature names and backward compatibility |
Date: |
Wed, 19 Sep 2018 13:36:17 -0300 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
On Tue, Sep 18, 2018 at 05:35:20PM +0200, Paolo Bonzini wrote:
> On 18/09/2018 16:22, Eduardo Habkost wrote:
> > On Tue, Sep 18, 2018 at 04:02:54PM +0200, Paolo Bonzini wrote:
> >> On 18/09/2018 15:14, Eduardo Habkost wrote:
> >>> If it broke something, we should restore the option names and
> >>> declare them as deprecated.
> >>
> >> I think in this particular case it's okay to add them back as no-ops,
> >> especially we'd actually want them to be customizable for user-mode
> >> emulation.
> >
> > We can make the flag work on user-mode emulation, but I wouldn't
> > like to keep QEMU silent if the option was explicitly set in the
> > command-line in system emulation, because it means the user or
> > some software component is really confused and trying to do
> > something that is never going to work.
>
> They just want to copy the host flags blindly into the guest. osxsave
> and ospke require some collaboration from the guest OS, but it should be
> pretty harmless to have them on the command line, because in the end the
> apps _should_ anyway be checking OSPKE. If somebody is writing such an
> app and is puzzled that OSPKE is missing, they should first of all ask
> themselves if they have installed the right guest OS.
I wouldn't say that a no-op option that would just confuse
apps/users is harmless. I really don't see any benefit in
keeping it.
I would agree with keeping them if it avoided additional
complexity on the app side. But if an app is copying host flags
to the QEMU command-line, the app should be already aware that
only a subset of CPUID flags is configurable in QEMU.
The only reason I can see for keeping the options is
compatibility with command-lines generated by current versions of
apps/libvirt. But that's exactly why we agreed on a deprecation
policy, isn't it?
--
Eduardo