Re: [Xen-devel] [PATCH RFC 20/31] x86: Improvements to in-hypervisor cpuid sanity checks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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