[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Dropped CPU feature names and backward compatibility
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] Dropped CPU feature names and backward compatibility |
Date: |
Wed, 19 Sep 2018 19:09:24 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
On 19/09/2018 18:36, Eduardo Habkost wrote:
> 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.
But how would it be confusing? It's perhaps worth warning, but that's it.
Paolo