<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.16.3"> </HEAD> <BODY> On Fri, 2008-07-11 at 22:22 +0100, Daniel P. Berrange wrote: <BLOCKQUOTE TYPE=CITE> <PRE> No, it only currently exposes VMX, SVM and PAE flags. Why exactly does oVirt need the full set ? They're a forever changing set across processor vendors and models and architectures which makes them fairly useless as a whole. Specific applications typically only care about specific flags hence we only exposed the ones clearly virt related so far Daniel </PRE> </BLOCKQUOTE> Other flags would be useful for verifying migration support. If we pulled back the full set of flags then we'd have a baseline of information to use in working out which hosts a guest can be migrated to. For example if a guest is running on a host that has SSE2 then we wouldn't want to live migrate that to a host that didn't have this feature as it would probably choke. Obviously the logic behind working out what would and wouldn't work is horrific, but if we pull back this data at least we have a foundation to work on if we decided to go down that path. VMware has done some work on this - for example allowing the NX bit to be masked, and have added some more cpu bitmasking features in 3.5, but I've not looked too closely into them. Aic </BODY> </HTML>