From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [HYBRID]: XEN_EMULATE_PREFIX in user process
Date: Thu, 28 Jun 2012 18:26:02 -0700
Message-ID: <20120628182602.6cc9b432@mantra.us.oracle.com>
References: <20120628180007.06bb3fd3@mantra.us.oracle.com>
	<20120629010903.GC4902@phenom.dumpdata.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: <20120629010903.GC4902@phenom.dumpdata.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: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Thu, 28 Jun 2012 21:09:03 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Thu, Jun 28, 2012 at 06:00:07PM -0700, Mukesh Rathor wrote:
> > Hi,
> > 
> > Booting latest upstream pv linux as dom0, I noticed dm_mapper, user
> > level process, is running with XEN_EMULATE_PREFIX cpuid. I am
> > wondering if the prefix is statically put there, or how its put
> > there?
> 
> That is impressive. It should be only be in the kernel via the pvops
> cpuid call which does this:
> 
>  252         asm(XEN_EMULATE_PREFIX "cpuid"
>  253                 : "=a" (*ax),
>  254                   "=b" (*bx),
>  255                   "=c" (*cx),
>  256                   "=d" (*dx)
>  257                 : "0" (*ax), "2" (*cx));
>  258 
> 
> 
> > 
> > For hybrid, the hvm container traps cpuid, so we don't need to
> > prefix cpuid. Less code if I don't have to worry about trapping the
> > invalid op. There seems places where the cpuid is run without the
> > xen prefix in user mode.
> 
> Right, you can make the .cpuid pvops call point to the native.

Yup. In the kernel I do that already.

> > 
> > BTW, for cpuid vmexit, if kernel mode I call pv_cpuid, if user
> > mode, I just return cpuid values, as that's what would happen
> > without the HVM container.
> 
> You mean in PV mode in user-space you would get the unfiltered cpuid
> value? Yes, that is true. Which is why I am surprised that dm_mapper
> (are you sure it is not a kernel thread?) is doing that.

User mode:

RIP: 0x0000000000400692 CS: 0x0033

[0]xkdb> dd 0x0000000000400680 32 0
0000000000400680:  89f88953e5894855 db8500000000b9d3
0000000000400690:  0f6e65780b0f0574 4e89045e890689a2

thanks,
Mukesh