* Alexander Graf <ag...@suse.de> [2012-01-16 14:52]: > > On 16.01.2012, at 21:13, Ryan Harper wrote: > > > * Alexander Graf <ag...@suse.de> [2012-01-16 13:52]: > >> > >> On 16.01.2012, at 20:46, Ryan Harper wrote: > >> > >>> * Alexander Graf <ag...@suse.de> [2012-01-16 13:37]: > >>>> > >>>> On 16.01.2012, at 20:30, Ryan Harper wrote: > >>>> > >>>>> * Alexander Graf <ag...@suse.de> [2012-01-08 17:53]: > >>>>>> When running QEMU without -cpu parameter, the user usually wants a sane > >>>>>> default. So far, we're using the qemu64/qemu32 CPU type, which > >>>>>> basically > >>>>>> means "the maximum TCG can emulate". > >>>>> > >>>>> it also means we all maximum possible migration targets. Have you > >>>>> given any thought to migration with -cpu best? > >>>> > >>>> If you have the same boxes in your cluster, migration just works. If > >>>> you don't, you usually use a specific CPU model that is the least > >>>> dominator between your boxes either way. > >>> > >>> Sure, but the idea behind -cpu best is to not have to figure that out; > >>> you had suggested that the qemu64/qemu32 were just related to TCG, and > >>> what I'm suggesting is that it's also the most compatible w.r.t > >>> migration. > >> > >> The, the most compatible wrt migration is -cpu kvm64 / kvm32. > >> > >>> it sounds like if migration is a requirement, then -cpu best probably > >>> isn't something that would be used. I suppose I'm OK with that, or at > >>> least I don't have a better suggestion on how to carefully push up the > >>> capabilities without at some point breaking migration. > >> > >> Yes, if you're interested in migration, then you're almost guaranteed to > >> have a toolstack on top that has knowledge of your whole cluster and can > >> do the least dominator detection over all of your nodes. On the QEMU level > >> we don't know anything about other machines. > >> > >>> > >>>> > >>>> The current kvm64 type is broken. Libgmp just abort()s when we pass it > >>>> in. So anything is better than what we do today on AMD hosts :). > >>> > >>> I wonder if it breaks with Cyris cpus... other tools tend to do runtime > >>> detection (mplayer). > >> > >> It probably does :). But then again those don't do KVM, do they? > > > > not following; mplayer issues SSE2, 3 and 4 instructions to see what > > works to figure out how to optimize; it doesn't care if the cpu is > > called QEMU64 or Cyrus or AMD. I'm not saying that we can't do better > > than qemu64 w.r.t best cpu to select by default, but there are plenty of > > applications that want to optimize their code based on what's available, > > but this is done via code execution instead of string comparision. > > The problem with -cpu kvm64 is that we choose a family/model that > doesn't exist in the real world, and then glue AuthenticAMD or > GenuineIntel in the vendor string. Libgmp checks for existing CPUs, > finds that this CPU doesn't match any real world IDs and abort()s. > > The problem is that there is not a single CPU on this planet in > silicon that has the same model+family numbers, but exists in > AuthenticAMD _and_ GenuineIntel flavors. We need to pass the host > vendor in though, because the guest uses it to detect if it should > execute SYSCALL or SYSENTER, because intel and amd screwed up heavily > on that one.
I forgot about this one. =( -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com
