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

[Tristan Gingold <tgingold@xxxxxxx>]

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