From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@suse.com>
Subject: Re: [PATCH 1/2] x86/xen: Set EFER.NX and EFER.SCE in
 PVH guests
Date: Fri, 05 Sep 2014 17:04:19 +0100
Message-ID: <5409FB230200007800031912@mail.emea.novell.com>
References: <1409926309-8345-1-git-send-email-david.vrabel@citrix.com>
	<1409926309-8345-2-git-send-email-david.vrabel@citrix.com>
	<5409E6200200007800031869@mail.emea.novell.com>
	<5409CCB0.3070402@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>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1XPvzo-00089d-56
	for xen-devel@lists.xenproject.org; Fri, 05 Sep 2014 16:04:20 +0000
In-Reply-To: <5409CCB0.3070402@citrix.com>
Content-Disposition: inline
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: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xenproject.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>
List-Id: xen-devel@lists.xenproject.org

>>> On 05.09.14 at 16:46, <david.vrabel@citrix.com> wrote:
> On 05/09/14 15:34, Jan Beulich wrote:
>>>>> On 05.09.14 at 16:11, <david.vrabel@citrix.com> wrote:
>>> --- a/arch/x86/xen/xen-head.S
>>> +++ b/arch/x86/xen/xen-head.S
>>> @@ -47,6 +47,36 @@ ENTRY(startup_xen)
>>>  
>>>  	__FINIT
>>>  
>>> +#ifdef CONFIG_XEN_PVH
>>> +
>>> +/**
>>> + * xen_pvh_cpu_early_init() - early PVH VCPU initialization
>>> + * @cpu: this cpu number (%rdi)
>>> + *
>>> + * Note: This is called as a function on the boot CPU and as the secondary
>>> + * CPU entry point.
>>> + */
>>> +ENTRY(xen_pvh_cpu_early_init)
>>> +	/* Gather features to see if NX implemented. */
>>> +	mov     $0x80000001, %eax
>>> +	cpuid
>>> +	mov     %edx,%esi
>>> +
>>> +	mov     $MSR_EFER, %ecx
>>> +	rdmsr
>>> +	bts     $_EFER_SCE, %eax
>>> +
>>> +	bt      $20,%esi
>>> +	jnc     1f      /* No NX, skip setting it */
>>> +	bts     $_EFER_NX, %eax
>>> +1:	wrmsr
>>> +
>>> +	cmp     $0,%rdi /* non-zero => secondary cpu */
>> 
>> Isn't Linux is specifically moving away from this assumption?
> 
> I don't think this is relevant.  Is Xen ever going boot with a non-zero
> VCPU?

That's not the question here. The question is - will CPU 0 ever be
possible to be brought down and back up? And I hope the answer
to this isn't "No, never".

>>> +	jne     cpu_bringup_and_idle
>>> +	ret
>>> +
>>> +#endif /* CONFIG_XEN_PVH */
>> 
>> Also, does all this really need to be done in assembly?
> 
> There's no usable stack until EFER.NX is set.  I couldn't think of a way
> to write this in C that would guarantee no stack use, so I didn't
> suggest it.
> 
> Can you think of a way?

No stack use is a very convincing argument for using assembly? I
must have overlooked it if that was said somewhere in a comment.

Jan