On Mon, Feb 17, 2014 at 05:17:51PM +0100, Andreas Färber wrote:
> Am 17.02.2014 14:58, schrieb Michael S. Tsirkin:
> > On Tue, Feb 04, 2014 at 03:12:43PM +0100, Andreas Färber wrote:
> >> Am 03.02.2014 20:01, schrieb Eduardo Habkost:
> >>> On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wro
Am 17.02.2014 14:58, schrieb Michael S. Tsirkin:
> On Tue, Feb 04, 2014 at 03:12:43PM +0100, Andreas Färber wrote:
>> Am 03.02.2014 20:01, schrieb Eduardo Habkost:
>>> On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wrote:
Il 21/01/2014 16:51, Andreas Färber ha scritto:
>>> We alre
On Mon, Feb 17, 2014 at 03:58:13PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 04, 2014 at 03:12:43PM +0100, Andreas Färber wrote:
> > Am 03.02.2014 20:01, schrieb Eduardo Habkost:
> > > On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wrote:
> > >> Il 21/01/2014 16:51, Andreas Färber ha
On Tue, Feb 04, 2014 at 03:12:43PM +0100, Andreas Färber wrote:
> Am 03.02.2014 20:01, schrieb Eduardo Habkost:
> > On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wrote:
> >> Il 21/01/2014 16:51, Andreas Färber ha scritto:
> > We already do that for other bits (e.g. XSAVE/OSXSAVE),
> >
Am 03.02.2014 20:01, schrieb Eduardo Habkost:
> On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wrote:
>> Il 21/01/2014 16:51, Andreas Färber ha scritto:
> We already do that for other bits (e.g. XSAVE/OSXSAVE),
>>> Please point me to the commit, a search for xsave did not come up with
On Tue, Jan 21, 2014 at 05:13:50PM +0100, Paolo Bonzini wrote:
> Il 21/01/2014 16:51, Andreas Färber ha scritto:
> >>> We already do that for other bits (e.g. XSAVE/OSXSAVE),
> >Please point me to the commit, a search for xsave did not come up with a
> >commit changing such a thing - either it did
On Tue, Jan 21, 2014 at 04:51:42PM +0100, Andreas Färber wrote:
> Am 21.01.2014 11:03, schrieb Paolo Bonzini:
> > Il 20/01/2014 23:13, Andreas Färber ha scritto:
> >> I don't like the argument that we can put arbitrary stuff in our model
> >> definitions and rely on TCG not having implemented it to
Il 21/01/2014 16:51, Andreas Färber ha scritto:
> We already do that for other bits (e.g. XSAVE/OSXSAVE),
Please point me to the commit, a search for xsave did not come up with a
commit changing such a thing - either it did not go through my queue or
it slipped me through: Bugs are no excuse to
Am 21.01.2014 11:03, schrieb Paolo Bonzini:
> Il 20/01/2014 23:13, Andreas Färber ha scritto:
>> I don't like the argument that we can put arbitrary stuff in our model
>> definitions and rely on TCG not having implemented it to make it
>> correct. Is x2apic something that TCG can never implement fo
On Tue, Jan 21, 2014 at 11:03:15AM +0100, Paolo Bonzini wrote:
> Il 20/01/2014 23:13, Andreas Färber ha scritto:
> > I don't like the argument that we can put arbitrary stuff in our model
> > definitions and rely on TCG not having implemented it to make it
> > correct. Is x2apic something that TCG
On Mon, Jan 20, 2014 at 11:13:11PM +0100, Andreas Färber wrote:
> Am 20.01.2014 15:36, schrieb Eduardo Habkost:
> > This enables x2apic on the following CPU models: Conroe, Penryn,
> > Nehalem, Westmere, Opteron_G[12345].
> >
> > Normally we try to keep the CPU model definitions as close as the re
Il 20/01/2014 23:13, Andreas Färber ha scritto:
> I don't like the argument that we can put arbitrary stuff in our model
> definitions and rely on TCG not having implemented it to make it
> correct. Is x2apic something that TCG can never implement for some
> reason? Then that needs a better explana
Am 20.01.2014 17:50, schrieb Eduardo Habkost:
> On Mon, Jan 20, 2014 at 05:27:18PM +0100, Andreas Färber wrote:
>> Am 20.01.2014 15:36, schrieb Eduardo Habkost:
>>> v1 was sent in September 2013:
>>> Message-Id: <1379704517-19177-1-git-send-email-ehabk...@redhat.com>
>>> http://article.gmane.or
Am 20.01.2014 15:36, schrieb Eduardo Habkost:
> This enables x2apic on the following CPU models: Conroe, Penryn,
> Nehalem, Westmere, Opteron_G[12345].
>
> Normally we try to keep the CPU model definitions as close as the real
> CPUs as possible, but x2apic can be emulated by KVM without host CPU
On Mon, Jan 20, 2014 at 05:27:18PM +0100, Andreas Färber wrote:
> Am 20.01.2014 15:36, schrieb Eduardo Habkost:
> > This enables x2apic on the following CPU models: Conroe, Penryn,
> > Nehalem, Westmere, Opteron_G[12345].
> >
> > Normally we try to keep the CPU model definitions as close as the re
Am 20.01.2014 15:36, schrieb Eduardo Habkost:
> This enables x2apic on the following CPU models: Conroe, Penryn,
> Nehalem, Westmere, Opteron_G[12345].
>
> Normally we try to keep the CPU model definitions as close as the real
> CPUs as possible, but x2apic can be emulated by KVM without host CPU
This enables x2apic on the following CPU models: Conroe, Penryn,
Nehalem, Westmere, Opteron_G[12345].
Normally we try to keep the CPU model definitions as close as the real
CPUs as possible, but x2apic can be emulated by KVM without host CPU
support for x2apic, and it improves performance by reduc
On Fri, Sep 20, 2013 at 04:15:17PM -0300, Eduardo Habkost wrote:
> This enables x2apic on the following CPU models: Conroe, Penryn,
> Nehalem, Westmere, Opteron_G[12345].
>
> Normally we try to keep the CPU model definitions as close as the real
> CPUs as possible, but x2apic can be emulated by KV
This enables x2apic on the following CPU models: Conroe, Penryn,
Nehalem, Westmere, Opteron_G[12345].
Normally we try to keep the CPU model definitions as close as the real
CPUs as possible, but x2apic can be emulated by KVM without host CPU
support for x2apic, and it improves performance by reduc
19 matches
Mail list logo
