qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Date: Mon, 21 Dec 2009 13:15:08 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0

On 12/20/2009 07:59 PM, 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.


Migration needs preparation beforehand. You can't take two random hosts with two random qemu flag sets and expect it to work.

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.

It does expose sse3 support (called pni in Linux IIRC). Not sure if qemu masks it, but the information is there.


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?

100% likely.

This is a classic management tool problem and the solution usually is a set of heuristics depending on how conservative the target audience is.

Right. My concern is with casual users upgrading their machine, not enterprise users who should be protected by their tools.

--
error compiling committee.c: too many arguments to function





reply via email to

[Prev in Thread] Current Thread [Next in Thread]