On 01/23/2012 05:30 PM, Daniel P. Berrange wrote:
> On Mon, Jan 23, 2012 at 05:23:32PM +0100, Paolo Bonzini wrote:
>> On 01/23/2012 05:03 PM, Daniel P. Berrange wrote:
>> > The qemu32/qemu64 models are weird in that the exact combination of
>> > CPUID flags does not match any actual
On Mon, Jan 23, 2012 at 05:23:32PM +0100, Paolo Bonzini wrote:
> On 01/23/2012 05:03 PM, Daniel P. Berrange wrote:
> > The qemu32/qemu64 models are weird in that the exact combination of
> > CPUID flags does not match any actual processor. kvm32 and kvm64 are
> > a better matc
On 01/23/2012 05:03 PM, Daniel P. Berrange wrote:
> > The qemu32/qemu64 models are weird in that the exact combination of
> > CPUID flags does not match any actual processor. kvm32 and kvm64 are
> > a better match when not using TCG. Use them when -cpu is only needed
> > to hardcode a 3
On Mon, Jan 23, 2012 at 04:57:21PM +0100, Jiri Denemark wrote:
> On Mon, Jan 23, 2012 at 14:11:11 +0100, Paolo Bonzini wrote:
> > The qemu32/qemu64 models are weird in that the exact combination of
> > CPUID flags does not match any actual processor. kvm32 and kvm64 are
> > a better match when not
On Mon, Jan 23, 2012 at 14:11:11 +0100, Paolo Bonzini wrote:
> The qemu32/qemu64 models are weird in that the exact combination of
> CPUID flags does not match any actual processor. kvm32 and kvm64 are
> a better match when not using TCG. Use them when -cpu is only needed
> to hardcode a 32-bit g
The qemu32/qemu64 models are weird in that the exact combination of
CPUID flags does not match any actual processor. kvm32 and kvm64 are
a better match when not using TCG. Use them when -cpu is only needed
to hardcode a 32-bit guest arch or for kvmclock.
Signed-off-by: Paolo Bonzini
---
src/qe
