[Qemu-devel] [PATCH] omit 3DNOW! CPUID bits from qemu64 CPU model

[Qemu-devel] [PATCH] omit 3DNOW! CPUID bits from qemu64 CPU model

[Andre Przywara]

Since we recently do not disable 3DNOW! support anymore, we should
avoid setting the bits in the default qemu64 CPU model to ease
migration. TCG does not support it anyway and even AMD deprecates
it's usage nowadays.
If you want to use it in KVM, use the phenom, athlon or host CPU
model.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>
---
 target-i386/helper.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/target-i386/helper.c b/target-i386/helper.c
index a214909..5ecc388 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -134,8 +134,7 @@ static x86_def_t x86_defs[] = {
             CPUID_PSE36,
         .ext_features = CPUID_EXT_SSE3,
         .ext2_features = (PPRO_FEATURES & 0x0183F3FF) | 
-            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX |
-            CPUID_EXT2_3DNOW | CPUID_EXT2_3DNOWEXT,
+            CPUID_EXT2_LM | CPUID_EXT2_SYSCALL | CPUID_EXT2_NX,
         .ext3_features = CPUID_EXT3_SVM,
         .xlevel = 0x8000000A,
         .model_id = "QEMU Virtual CPU version " QEMU_VERSION,
-- 
1.6.1.3

Re: [Qemu-devel] [PATCH] omit 3DNOW! CPUID bits from qemu64 CPU model

[Alexander Graf]

On 16.07.2009, at 14:49, Andre Przywara wrote:

> Since we recently do not disable 3DNOW! support anymore, we should
> avoid setting the bits in the default qemu64 CPU model to ease
> migration. TCG does not support it anyway and even AMD deprecates
> it's usage nowadays.

TCG does not implement it but it was enabled in the qemu64 type? That  
sounds like a serious bug people would have found before.

I really think we should try and keep the "qemu64" type (TCG  
capabilities) and the "kvm safe" type separate. IMHO the best scenario  
would be a -cpu "safe" type, used as default, that is the common  
dominator between KVM on VMX, KVM on SVM and TCG.

That would also make it easier to know where to put other fancy  
features like "SVM" :-).

Alex

Re: [Qemu-devel] [PATCH] omit 3DNOW! CPUID bits from qemu64 CPU model

[Jamie Lokier]

Alexander Graf wrote:
> 
> On 16.07.2009, at 14:49, Andre Przywara wrote:
> 
> >Since we recently do not disable 3DNOW! support anymore, we should
> >avoid setting the bits in the default qemu64 CPU model to ease
> >migration. TCG does not support it anyway and even AMD deprecates
> >it's usage nowadays.
> 
> TCG does not implement it but it was enabled in the qemu64 type? That  
> sounds like a serious bug people would have found before.

Almost nobody uses 3DNow! with a 64-bit guest, so it's not so
easy to notice.

But I've have expected people running 32-bit guests on a qemu64 CPU to
notice, even if it's just the prefetch instructions...  unless those
happen to overlap with NOPs on non-3DNow! hardware.  (I'm too lazy to check).

> I really think we should try and keep the "qemu64" type (TCG  
> capabilities) and the "kvm safe" type separate. IMHO the best scenario  
> would be a -cpu "safe" type, used as default, that is the common  
> dominator between KVM on VMX, KVM on SVM and TCG.

qemu32 => TCG 32-bit
qemu64 => TCG 64-bit

safe32 => common between KVM and TCG, 32-bit
safe64 => common between KVM and TCG, 64-bit

?

> That would also make it easier to know where to put other fancy  
> features like "SVM" :-)

Can't we use SVM emulation with TCG and KVM both?

-- Jamie

Re: [Qemu-devel] [PATCH] omit 3DNOW! CPUID bits from qemu64 CPU model

[Alexander Graf]

On 16.07.2009, at 18:01, Jamie Lokier wrote:

> Alexander Graf wrote:
>>
>> On 16.07.2009, at 14:49, Andre Przywara wrote:
>>
>>> Since we recently do not disable 3DNOW! support anymore, we should
>>> avoid setting the bits in the default qemu64 CPU model to ease
>>> migration. TCG does not support it anyway and even AMD deprecates
>>> it's usage nowadays.
>>
>> TCG does not implement it but it was enabled in the qemu64 type? That
>> sounds like a serious bug people would have found before.
>
> Almost nobody uses 3DNow! with a 64-bit guest, so it's not so
> easy to notice.
>
> But I've have expected people running 32-bit guests on a qemu64 CPU to
> notice, even if it's just the prefetch instructions...  unless those
> happen to overlap with NOPs on non-3DNow! hardware.  (I'm too lazy  
> to check).
>
>> I really think we should try and keep the "qemu64" type (TCG
>> capabilities) and the "kvm safe" type separate. IMHO the best  
>> scenario
>> would be a -cpu "safe" type, used as default, that is the common
>> dominator between KVM on VMX, KVM on SVM and TCG.
>
> qemu32 => TCG 32-bit
> qemu64 => TCG 64-bit
>
> safe32 => common between KVM and TCG, 32-bit
> safe64 => common between KVM and TCG, 64-bit

Yeah. Maybe only "safe" and always assume x86_64? But then comes  
Intel ... sigh.

>> That would also make it easier to know where to put other fancy
>> features like "SVM" :-)
>
> Can't we use SVM emulation with TCG and KVM both?

We can use SVM emulation with TCG and KVM on SVM. We can't on KVM with  
VMX and Xen HVM. For KVM it's fine though, because the feature gets  
masked out if it's not supported.

Still, SVM isn't migratable on KVM atm, so let's better disable it for  
"safe".

Alex

Re: [Qemu-devel] [PATCH] omit 3DNOW! CPUID bits from qemu64 CPU model

[Jamie Lokier]

Alexander Graf wrote:
> >safe32 => common between KVM and TCG, 32-bit
> >safe64 => common between KVM and TCG, 64-bit
> 
> Yeah. Maybe only "safe" and always assume x86_64? But then comes  
> Intel ... sigh.

Why x86_64?  Some of use run KVM on 32-bit host CPUs.
They're not antiques yet :-)

-- Jamie

> >>That would also make it easier to know where to put other fancy
> >>features like "SVM" :-)
> >
> >Can't we use SVM emulation with TCG and KVM both?
> 
> We can use SVM emulation with TCG and KVM on SVM.

Yay!  Oh, wait, I have VMX instead :-/

> We can't on KVM with VMX and Xen HVM. For KVM it's fine though,
> because the feature gets masked out if it's not supported.

Ok.  I'm a bit surprised SVM isn't just easy to emulate on VMX, if
it's done by emulating instructions and state transitions.  Is SVM
particularly good for nesting so that you don't need much emulation
code in KVM's in-kernel minimal emulator?

I'm biased as I was hoping to run nested KVMs on my VMX 32-bit Intel :-D

> Still, SVM isn't migratable on KVM atm, so let's better disable it for  
> "safe".

I agree, non-migratable things should be disabled for "safe".

Is it because there's hidden state, or simply unimplemented save/load code?

-- Jamie

Re: [Qemu-devel] [PATCH] omit 3DNOW! CPUID bits from qemu64 CPU model

[Alexander Graf]

On 16.07.2009, at 18:36, Jamie Lokier wrote:

> Alexander Graf wrote:
>>> safe32 => common between KVM and TCG, 32-bit
>>> safe64 => common between KVM and TCG, 64-bit
>>
>> Yeah. Maybe only "safe" and always assume x86_64? But then comes
>> Intel ... sigh.
>
> Why x86_64?  Some of use run KVM on 32-bit host CPUs.
> They're not antiques yet :-)

Well, Intel is the only vendor that has virtualization enabled CPUs  
that do _not_ support long mode. That's why the "sigh" is in there.

>>>> That would also make it easier to know where to put other fancy
>>>> features like "SVM" :-)
>>>
>>> Can't we use SVM emulation with TCG and KVM both?
>>
>> We can use SVM emulation with TCG and KVM on SVM.
>
> Yay!  Oh, wait, I have VMX instead :-/
>
>> We can't on KVM with VMX and Xen HVM. For KVM it's fine though,
>> because the feature gets masked out if it's not supported.
>
> Ok.  I'm a bit surprised SVM isn't just easy to emulate on VMX, if
> it's done by emulating instructions and state transitions.  Is SVM
> particularly good for nesting so that you don't need much emulation
> code in KVM's in-kernel minimal emulator?

Give it a go :-). Interception masks are different on both and  
probably some state is too. I'm pretty sure the TPR stuff is handled  
completely differently on both.

But maybe it's possible to hack something together that's good enough  
for running KVM. I don't think you'd be that fortunate about other  
hypervisors :o.

For Intel, doing PV nesting is probably more useful.

> I'm biased as I was hoping to run nested KVMs on my VMX 32-bit  
> Intel :-D
>
>> Still, SVM isn't migratable on KVM atm, so let's better disable it  
>> for
>> "safe".
>
> I agree, non-migratable things should be disabled for "safe".
>
> Is it because there's hidden state, or simply unimplemented save/ 
> load code?

Mostly unimplemented save/load code. The hidden state can be worked  
around by always exiting the guest before we do a migration.

Alex

Re: [Qemu-devel] [PATCH] omit 3DNOW! CPUID bits from qemu64 CPU model

[Andre Przywara]

Alexander Graf wrote:
> 
> On 16.07.2009, at 14:49, Andre Przywara wrote:
> 
>> Since we recently do not disable 3DNOW! support anymore, we should
>> avoid setting the bits in the default qemu64 CPU model to ease
>> migration. TCG does not support it anyway and even AMD deprecates
>> it's usage nowadays.
> 
> TCG does not implement it but it was enabled in the qemu64 type? That 
> sounds like a serious bug people would have found before.
Yes, it was enabled in the qemu64 type since "the dawn of time". But at 
the same moment it was unconditionally (both for TCG and KVM) masked out 
later, so there were no 3DNOW bits at any time. Commit 671e4676 changed 
that to be only applicable to TCG. So in the last three weeks or so by 
default there were 3DNOW bits in KVM on AMD processors.
This is a particular problem with DirectX9 (WindowsXP), which still uses 
3DNow if available.

> I really think we should try and keep the "qemu64" type (TCG 
> capabilities) and the "kvm safe" type separate. IMHO the best scenario 
> would be a -cpu "safe" type, used as default, that is the common 
> dominator between KVM on VMX, KVM on SVM and TCG.
Well, I'd like to leave TCG out of the migration theme by default. If 
you seriously use KVM and migration, I suppose TCG is not an option for 
you. It's a nice thing to have, but for different things than KVM.
But I will check how much difference there is between Prescott-2M, 
K8RevF and TCG, maybe we can leave it in.

Regards,
Andre.

> 
> That would also make it easier to know where to put other fancy features 
> like "SVM" :-).
> 
> Alex
> 


-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 488-3567-12
----to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632