Re: [Xen-ia64-devel] Re: [patch 5/5] IA64: Kexec: Use a separate RID for EFI

[tgingold@xxxxxxx]

Quoting Simon Horman <horms@xxxxxxxxxxxx>:

[...]

> I'll add some more documentation but here is a run down:
>
> 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,
> except for the 0th small block which is used by Xen.
Correct.

> By default each large block is 18 bits wide. And each small block is
> 1/64 the width of a large block, or in other words, 12 bits wide. These
> default values are the ones that end up being used on my RX2620 box.
18 bits is the minimum and 1/64 is the current maximum so 12 bits is the
minimum.


> What isn't obvious to me is how the 0th small block is divided up.
> 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
> ad-hoc fashion.
The 0th small block is not used except during startup.  Once domains are
run, hypervisor uses domains RIDs.

> 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)
>
> 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
> limitation. The hardware sets the limit of the with of this area to
> between 17 and 24 bits. I I believe that on Itanium it is 17 and on
18 is the minimum, 24 the maximum.
> Itanium2 it is 24 and my  RX2620 box seems to have 24 bits.  This means
> that N should always between 25 (8+17)  and 32 (8+24).
>
> As we are only using the first 4 bits (3 bits in area d and 1 bit in
> area e) of RID space, and our small-block should have 12 bits, this
> should be fine - which is nice because these are the IDs that
> the hypervisor is using, as set in _start().
As stated above only until RIDs are set by domain 0.

> I couldn't find a place where the hypervisor gave itself additional RIDs
> to play with that weren't realated to a domain, so I just took the next
> slot by defining IA64_REGION_ID_EFI=1, so we can use the following RIDs.
>
> 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.
Correct.


> However, I am not entirely convinced that this avoids an RID collision.
> Mostly because I'm not entirely convinced that other RIDs aren't being
> used. If so, then I guess there is an allocation mechanism that I
> haven't managed to find yet.
There is no possible collision.  Don't worry!

Tristan.

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