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:
>
> Hi,
>
> I try to fix the comments according to my knowledge.
>
> [...]
> > +/*
> > + * According to xen/arch/ia64/xen/regionreg.c the RID space is broken
> > + * up into chunks, one per domain, and 0th block is for Xen. The 0th block
> > + * is broken up into small blocks, which are used for metaphisical mappins,
>
> metaphysical
>
> > + * except for the 0th small block which is used by Xen.
> > + *
> > + * By default each large block is 18 bits wide, which is also the minimum
> > + * width. Each small block is by default 1/64 the width of a large block,
> > + * which is also the maximum devision. In other words each small block is
>
> division (?)
>
> > + * at least 12 bits wide.
> > + *
> > + * What isn't obvious to me is how the 0th small block is divided up.
>
> small block 0 was not used (except during Xen boot).
>
> > + * While xen/arch/ia64/xen/regionreg.c seems to handle allocating RIDs for
> > + * domains, they hypervisor's RIDs seem to be handled in a bit more of an
> their (?)
> > + * ad-hoc fashion.
>
> No, there are no hypervisor's RIDs. The hypervisor always use domain regions.
>
> > + * In xen/include/asm-ia64/mmu_context.h there is IA64_REGION_ID_KERNEL.
> > + * This is used to form an RID in the follwing way:
> > + *
> > + * a: bit 0: VHPT
> > + * b: bit 1: reserved (0)
> > + * c: bits 2-7: log 2 page_size
> > + * d: bits 8-10: Region (0-7, corresponding to the 8 region registers)
> > + * e: bits 10-N: IA64_REGION_ID_KERNEL (0)
> > + * f: bits N-53: reserved (0)
>
> 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 ?
When I first wrote this document I was under the impression that
the hypervisor had its own RIDs, I need to clean this up a bit.
I will rework this description but I think that the important point is
that small block 0 is not used other than during early Xen boot,
so it is quite safe to use an RID out of this range for EFI without
risking conflicting with an RID which is used by a domain.
>
> > + *
> > + * N is defined by the platform. Areas c and d above form the RID, it just
> > + * happens to be further divided in two due to the way that its value is
> > + * calculated buy the code. This subdivision does not reflect any hardware
>
> by
>
> > + * limitation. The hardware sets the limit of the with of this area to
> > + * between 18 and 24 bits.
> > + *
> > + * As we are only using the first 4 bits (3 bits in area d and 1 bit in
> > + * area e) of RID space it easily fits inside the 0th small block, which
> > + * is 12 bits wide.
> > + *
> > + * For EFI we use the following RID
> > + *
> > + * a: bit 0: VHPT (1)
> > + * b: bit 1: reserved (0)
> > + * c: bits 2-7: log 2 page_size
> > + * d: bits 8-10: Region (0-7, corresponding to the 8 region registers) +
> > + * e: bits 10-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 still only using 4 bits of RID
> > + * space, so it shouldn't have any chance of running into an adjacent
> > + * small-block.
> > + *
> > + * 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 that 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.
>
> Tristan.
--
Horms
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home