On 21/01/16 17:02, Jan Beulich wrote:
>>>> On 16.12.15 at 22:24, <andrew.coop...@citrix.com> 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@lists.xen.org
http://lists.xen.org/xen-devel
