On 21/01/16 17:21, Andrew Cooper wrote:
> 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.)
I have just double checked. 32bit PV guests on Intel definitely can use
syscall.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
