Re: [Qemu-devel] cpuid problem in upstream qemu with kvm

[Alexander Graf]

On 20.12.2009, at 18:59, Anthony Liguori wrote:

> Gleb Natapov wrote:
>> Windows is a mystery box, so we can speculate as much as we want about it.
>> If you don't like something just say "it may break Windows" :) Losing
>> activation does sound like an issue too.
>>  
> 
> Downgrading seems more likely to cause problems.  Considering running mplayer 
> in a guest.  If it detects SSE3 in one host and migrate to another host that 
> doesn't have SSE3, you'll be running an instruction stream that uses 
> instructions the processor doesn't support resulting in the application 
> faulting due to an illegal operation.

Yeah, migration with -cpu host doesn't sound like a sane thing to do.

> KVM's cpuid filter doesn't help here because it won't attempt to mask things 
> like sse3.  It would be insane to emulate sse3 too.

Well, I wouldn't be too sure on that one. Software may use SSE3 instructions to 
access MMIO in which case we do have to emulate it.

> This is a classic problem with live migration.  You can detect this scenario 
> and potentially block the migration, but honestly, how likely is it that any 
> given guest is using an obscure feature?  This is a classic management tool 
> problem and the solution usually is a set of heuristics depending on how 
> conservative the target audience is.

I agree. I think the discussion was about setting -cpu host to the default? I 
was merely wondering what'd keep us from doing that, as management software 
would just -cpu qemu64 and be good.

Btw: I'd actually prefer if it'd be called -cpu safe or so. That way we could 
differenciate between "tcg could run the code" and "doesn't break migration". 
The former one is -cpu qemu64 and coincidently it matches with the latter in 
most cases, but I'm not sure it'd keep that way. Think of default enablement of 
nested SVM...

Alex