* Alexander Graf <agraf@xxxxxxx> [2012-01-16 14:52]: > > On 16.01.2012, at 21:13, Ryan Harper wrote: > > > * Alexander Graf <agraf@xxxxxxx> [2012-01-16 13:52]: > >> > >> On 16.01.2012, at 20:46, Ryan Harper wrote: > >> > >>> * Alexander Graf <agraf@xxxxxxx> [2012-01-16 13:37]: > >>>> > >>>> On 16.01.2012, at 20:30, Ryan Harper wrote: > >>>> > >>>>> * Alexander Graf <agraf@xxxxxxx> [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 ryanh@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
