From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH RFC 20/31] x86: Improvements to
 in-hypervisor cpuid sanity checks
Date: Thu, 21 Jan 2016 18:15:42 +0000
Message-ID: <56A1204E.8080200@citrix.com>
References: <1450301073-28191-1-git-send-email-andrew.cooper3@citrix.com>
	<1450301073-28191-21-git-send-email-andrew.cooper3@citrix.com>
	<56A11D3702000078000C9B82@prv-mh.provo.novell.com>
	<56A113AA.7030600@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <56A113AA.7030600@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

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.cooper3@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