Stephane Eranian wrote: >> >> The main issue is migration (and save/restore). If you migrate to a >> host with fewer capabilities, applications may fail when they use >> unavailable instructions that they successfully detected earlier. >> >> > In the case of heterogeneous migration, clearly performance counters > will not work well, especially for unmodified guests.
Right. > But I can also > see problems when migrating from Intel Core to older P4 for instance. > > If the guest cpuid is set to a least common denominator, it should work. >> Upstream qemu already has a -cpu (or similar) switch for non-x86; we can >> probably use that. >> >> > > Probably, but in my particular case, you'd have to be able to specify > vendor/family/model. > > Right. It will have to be quite elaborate. >> (there's another possible issue - some future features may require >> support from the hypervisor - that may conflict with defaulting to to >> the host feature set. maybe kvm should mask out any unknown features) >> >> > > The question is how do you identify unknown features which do require > KVM support? > > Yes. Obviously we don't know anything about future features, so we can just mask out any feature that is unknown today, and update the mask when new features are available (whether they require kernel support or not). This masking can be performed in user space, so upgrading is not too hard (or even allow a command-line override). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
