[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] 1GB hugepages and intel_xc_cpuid_policy by default disables it.
>>> On 13.01.14 at 12:38, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: > On Mon, 2014-01-13 at 11:30 +0000, Jan Beulich wrote: >> In fact I can't see where this would be forced off: xc_cpuid_x86.c >> only does so in the PV case, and all hvm_pse1gb_supported() is >> that the CPU supports it and the domain uses HAP. > > Took me a while to spot it too: > static void intel_xc_cpuid_policy( > [...] > case 0x80000001: { > int is_64bit = hypervisor_is_64bit(xch) && is_pae; > > /* Only a few features are advertised in Intel's 0x80000001. > */ > regs[2] &= (is_64bit ? bitmaskof(X86_FEATURE_LAHF_LM) : 0) | > bitmaskof(X86_FEATURE_ABM); > regs[3] &= ((is_pae ? bitmaskof(X86_FEATURE_NX) : 0) | > (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) | > (is_64bit ? bitmaskof(X86_FEATURE_SYSCALL) : 0) | > (is_64bit ? bitmaskof(X86_FEATURE_RDTSCP) : 0)); > break; > } > > > Which masks anything which is not explicitly mentioned. (PAGE1GB is in > regs[3], I think). Ah, okay. The funs of white listing on HVM vs black listing on PV again. > The AMD version is more permissive: > > regs[3] &= (0x0183f3ff | /* features shared with 0x00000001:EDX */ > (is_pae ? bitmaskof(X86_FEATURE_NX) : 0) | > (is_64bit ? bitmaskof(X86_FEATURE_LM) : 0) | > bitmaskof(X86_FEATURE_SYSCALL) | > bitmaskof(X86_FEATURE_MP) | > bitmaskof(X86_FEATURE_MMXEXT) | > bitmaskof(X86_FEATURE_FFXSR) | > bitmaskof(X86_FEATURE_3DNOW) | > bitmaskof(X86_FEATURE_3DNOWEXT)); > > (but I didn't check if PAGE1GB is in that magic number...) It's not - it's bit 26. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |