[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 20/31] x86: Improvements to in-hypervisor cpuid sanity checks
On 21/01/16 17:02, Jan Beulich wrote: >>>> On 16.12.15 at 22:24, <andrew.cooper3@xxxxxxxxxx> wrote: >> @@ -864,69 +865,27 @@ void pv_cpuid(struct cpu_user_regs *regs) >> >> cpuid_count(a, c, &a, &b, &c, &d); >> >> - if ( (regs->eax & 0x7fffffff) == 0x00000001 ) >> - { >> - /* Modify Feature Information. */ >> - if ( !cpu_has_apic ) >> - __clear_bit(X86_FEATURE_APIC, &d); >> - >> - if ( !is_pvh_domain(currd) ) >> - { >> - __clear_bit(X86_FEATURE_PSE, &d); >> - __clear_bit(X86_FEATURE_PGE, &d); >> - __clear_bit(X86_FEATURE_PSE36, &d); >> - __clear_bit(X86_FEATURE_VME, &d); >> - } >> - } > This I understand goes away because pv_featureset[] never has > those set? > >> case 0x80000001: >> - /* Modify Feature Information. */ >> - if ( is_pv_32bit_domain(currd) ) >> - { >> - __clear_bit(X86_FEATURE_LM % 32, &d); >> - __clear_bit(X86_FEATURE_LAHF_LM % 32, &c); >> - } >> - if ( is_pv_32bit_domain(currd) && >> - boot_cpu_data.x86_vendor != X86_VENDOR_AMD ) >> - __clear_bit(X86_FEATURE_SYSCALL % 32, &d); > But what about these 32-bit specific removals? LM, from the deep feature dependency removal in libxc, when it is known that the domain is 32bit. For SYSCALL, as far as I can tell, the logic is wrong. 32bit compat mode code on Intel can use SYSCALL, as Xen is running in Long mode. (This is opposite to the AMD case where 32bit compat code cannot use SYSENTER, because Xen is in Long mode.) > Overall this of course makes things quite a bit more readable. And there is more to come. By the time my cpuid phase 2 plans are complete, all validitiy checks will be done at the set_cpuid_policy hypercall boundary, meaning that all these time-of-use checks can be dropped. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |