[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [HYBRID]: XEN_EMULATE_PREFIX in user process
On Thu, 28 Jun 2012 21:09:03 -0400 Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |