[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 at 18:21, <andrew.cooper3@xxxxxxxxxx> wrote: > On 21/01/16 17:02, Jan Beulich wrote: >>>>> On 16.12.15 at 22:24, <andrew.cooper3@xxxxxxxxxx> wrote: >>> 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.) Intel doesn't even document a CSTAR MSR. >> 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. And arguably it should have been that way from the beginning - re-calculating all of these every time is ineffective, even if the overhead isn't _that_ high. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |