[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] Why is cpl read as 0 in para-virtualization ?


  • To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Wed, 1 Mar 2006 09:01:25 -0800
  • Delivery-date: Wed, 01 Mar 2006 17:01:41 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcY9S2KhnzPSoFmpRMuY2INXTurOMwABVKgA
  • Thread-topic: [Xen-ia64-devel] Why is cpl read as 0 in para-virtualization ?

> > > while I was modifying xen_early_setup, I tried to replace dcr
> > > kludge using
> > > cpl.  Unfortunatly, it doesn't work since cpl is read as 0
> > > (see vcpu.c).
> > > So my question is simple: why ?
> >
> > I think some places in Linux/ia64 determine whether code
> > is running in kernel or user mode by checking psr.cpl.
> Correct.
> One place is user_mode() is ptrace.h.
> Currently it is true if cpl != 0.  I have made a simple test: 
> I have changed 
> the code to cpl == 3, and cpl reads as 2.  Linux is booting 
> (dom0+domU).

IIRC, there was at least one place in assembly code which
checked psr.cpl==0 (maybe mca code?) but this was a longtime
ago (possibly 2.4.x) so the code may be gone.

There is Itanium architecture work going on to establish a
mechanism for determining whether an OS is running native or
as a (paravirtualized or fully-virtualized) guest.  I don't
know the status of this but am pretty sure it was checking
a currently reserved bit, possibly in cr.dcr.

Dan

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.