Messages in this thread | | >>> "H. Peter Anvin" <hpa@zytor.com> 31.01.10 19:43 >>> >On 01/31/2010 10:02 AM, Jan Beulich wrote: >>>>> "H. Peter Anvin" 01/31/10 2:42 AM >>> >>> + * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification >>> + * of a Xen host. >>> + */ >>> +#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */ >>> +#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */ >>> +#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */ >>> >>> I hope you know this spells "MMXenVMMXenV". The ordering is ecx-edx-ebx >>> (register numbers 1, 2, 3). >> >> According to the documentation I have, the ordering is EBX-EDX-ECX, >> so indeed the spelling would seem broken, but since this is an interface >> header taken directly from Xen, it's got to be (and it works) that way. >> Odd. >> > >It's probably a bug that's now cast in stone. That happends. I just >had to be picky. (And yes, it's ebx-edx-ecx; see my second email.)
The "good" thing is that this is not on leaf 0, but on leaf 0x4000??00, i.e. "normal" code would never display this garbled string.
Jan
| |