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 ?
> + *
> + * 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.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home