This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [RFC PATCH 15/33] move segment checks to subarch

On Tue, 2006-07-18 at 12:25 -0700, Chris Wright wrote:
> * Rusty Russell (rusty@xxxxxxxxxxxxxxx) wrote:
> > On Tue, 2006-07-18 at 00:00 -0700, Chris Wright wrote:
> > > plain text document attachment (i386-segments)
> > > We allow for the fact that the guest kernel may not run in ring 0.
> > > This requires some abstraction in a few places when setting %cs or
> > > checking privilege level (user vs kernel).
> > 
> > Zach had an alternate patch for this, which didn't assume the kernel ran
> > in a compile-time known ring, but is otherwise very similar.  I've put
> > it below for discussion (but Zach now tells me the asm parts are not
> > required: Zach, can you mod this patch and comment?).
> This patch also doesn't have a compile time known ring, it's using
> get_kernel_cs() because the Xen method for booting native is dynamic and
> would resolve to ring 0 in that case (XENFEAT_supervisor_mode_kernel).

I was referring to the different ways the two patches figure out whether
we're in user mode:

 static inline int user_mode(struct pt_regs *regs)
       return (regs->xcs & USER_MODE_MASK) != 0;

Where you have for native:
        #define USER_MODE_MASK 3
vs Xen:
        #define USER_MODE_MASK 2

Zach's patch does this:

 static inline int user_mode(struct pt_regs *regs)
        return (regs->xcs & SEGMENT_RPL_MASK) == 3;

I'm no x86pert, but the latter seems more generic to me (user mode is
ring 3, vs. usermode is anything >= 2).  Perhaps they are in fact

Help! Save Australia from the worst of the DMCA: http://linux.org.au/law

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>