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
|