On Wed, Sep 19, 2018 at 07:09:24PM +0200, Paolo Bonzini wrote:
> 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 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
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
> >>>
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 ok
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
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.
Paolo
On Tue, Sep 18, 2018 at 03:26:18PM +0200, Jiri Denemark wrote:
> On Tue, Sep 18, 2018 at 10:14:45 -0300, Eduardo Habkost wrote:
> > On Tue, Sep 18, 2018 at 03:07:35PM +0200, Jiri Denemark wrote:
> > > Sure, libvirt could just avoid passing feature=off for any feature which
> > > is not supported by
On Tue, Sep 18, 2018 at 10:14:45 -0300, Eduardo Habkost wrote:
> On Tue, Sep 18, 2018 at 03:07:35PM +0200, Jiri Denemark wrote:
> > Sure, libvirt could just avoid passing feature=off for any feature which
> > is not supported by the QEMU binary it is about to start since such
> > feature should be
On Tue, Sep 18, 2018 at 03:07:35PM +0200, Jiri Denemark wrote:
> Hi,
>
> I noticed two x86_64 CPU features were removed from QEMU in 3.0.0:
> - ospke removed by 9ccb9784b57
> - osxsave removed by f1a23522b03
>
> More precisely, the CPUID bits are still there (and for example Icelake
> CPU
Hi,
I noticed two x86_64 CPU features were removed from QEMU in 3.0.0:
- ospke removed by 9ccb9784b57
- osxsave removed by f1a23522b03
More precisely, the CPUID bits are still there (and for example Icelake
CPU model has the ospke bit set), but the string representations were
removed. Thu
10 matches
Mail list logo