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