Re: [Xen-ia64-devel] Re: [patch 01/12] ia64: kexec: Define macros for EFI RID

[Simon Horman <horms@xxxxxxxxxxxx>]

On Fri, Apr 25, 2008 at 02:38:15PM +1000, Simon Horman wrote:
> On Fri, Apr 25, 2008 at 06:30:00AM +0200, Tristan Gingold wrote:
> > [...]
> > 
> > On Fri, Apr 25, 2008 at 06:25:37AM +0200, Tristan Gingold wrote:
> > > On Fri, Apr 25, 2008 at 01:57:04PM +1000, Simon Horman wrote:
> > > 
> > > To my best knowledge, this is linux specific (ie not used by Xen except 
> > > during
> > > boot time).  So I suppose you are explaining how to use an RID compatible
> > > with Linux ?
> > 
> > After a minute, I don't think we need to choose an RID compatible with 
> > Linux,
> > right ?  If so, why not using simpler RIDs in head.S as well as a simpler
> > XEN_EFI_RID ?
> 
> That is true, the RID does not need to be compatible with Linux.
> I'll look into your idea of using something in head.S.
> 
> > (To be honnest, this could be fixed after - I just think the comment is a
> >  little bit misleading).
> 
> Sorry about that. When I wrote that comment I was somewhat confused
> myself. I intended it to be more of a discussion point than a
> description of what is going on. 

Below is an updated version of the description. I think that
the key point is that using a RID from the 0th small-block
will protect memory inserted using that RID from access
by domains.

The rest is just an explanation of how I chose an RID in
the 0th small-block.

-- 
Horms

/*
 * According to xen/arch/ia64/xen/regionreg.c the RID space is broken up
 * into large-blocks. Each block belongs to a domain, except 0th block,
 * which is broken up into small-blocks. The small-blocks are used for
 * metaphysical mappings, again one per domain, except for the 0th
 * small-block which is unused other than very early on in the
 * hypervisor boot.
 *
 * By default each large-block is 18 bits wide, which is also the minimum
 * allowed width for a block. Each small-block is by default 1/64 the width
 * of a large-block, which is the maximum division allowed. In other words
 * each small-block is at least 12 bits wide.
 *
 * The portion of the 0th small-block that is used early on during
 * the hypervisor boot relates to IA64_REGION_ID_KERNEL, which is
 * used to form an RID using the following scheme which seems to be
 * have been inherited from Linux:
 *
 * a: bits 0-2: Region Number (0-7)
 * b: 3-N:      IA64_REGION_ID_KERNEL (0)
 * c: N-23:     reserved (0)
 *
 * N is defined by the platform.
 *
 * For EFI we use the following RID:
 *
 * a: bits 0-2:  Region Number (0-7)
 * e: bits 3-N:  IA64_REGION_ID_KERNEL (1)
 * f: bits N-53: reserved (0)
 *
 * + Only 0 is used as we only need one RID. Its not really important
 *   what this number is, so long as its between 0 and 7.
 *
 * The nice thing about this is that we are only using 4 bits of RID
 * space, so it shouldn't have any chance of running into an adjacent
 * small-block since small-blocks are at least 12 bits wide.
 *
 * It would actually be possible to just use a IA64_REGION_ID_KERNEL
 * based RID for EFI use. The important thing is that it is in the 0th
 * small block, and thus not available to domains. But as we have
 * lots of space, its seems to be nice and clean to just use a separate
 * RID for EFI.
 *
 * This can be trivially changed by updating the definition of XEN_EFI_RID.
 *
 * For reference, the RID is used to produce the value inserted
 * in to a region register in the following way:
 *
 * A: bit 0:     VHPT (0 = off, 1 = on)
 * B: bit 1:     reserved (0)
 * C: bits 2-7:  log 2 page_size
 * D: bits 8-N:  RID
 * E: bits N-53: reserved (0)
 */


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