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
