search for: xc_cpuid_apply_polici

Hi Keir, For HVM guests, all cpuid Fn''s going through domain_cpuid() iterate over the loop and then return 0 for all four registers. Guests OS''s and cpuid tools in HVM which query for cpuid Fn 0000.0000 %eax and 8000.0000 %eax, see the value 0 and think, Xen emulates oldish 386/486 CPUs. This leads to strange boot failures, "your CPU does not support long mode" or

''xl mem-set'' should update memory info in xenstore''s vm info. Signed-off-by: Yu Zhiguo <yuzg@cn.fujitsu.com> diff -r ccae861f52f7 -r 5847ce53f5dc tools/libxl/libxl.c --- a/tools/libxl/libxl.c Thu May 06 11:59:55 2010 +0100 +++ b/tools/libxl/libxl.c Sat May 08 01:38:51 2010 +0800 @@ -2290,11 +2290,22 @@ uint32_t videoram; char *videoram_s = NULL;

* Introduce new variants of the logging functions which include errno values (converted using strerror) in the messages passed to the application''s logging callback. * Use the new errno-including logging functions everywhere where appropriate. In general, xc_... functions return errno values or 0; xs_... functions return 0 or -1 (or some such) setting errno. * When

Changes since v1: - Fix a double-free bug introduced by v1, pointed out by Stefano where internal pointer was being passed back to caller from libxl_create_stubdom() 8<---------------------------------------------------------------------- Currently scratch variables allocated by libxl have the same lifetime as the context. While this is suitable for one off invocations of xl. It is not