WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

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

To: Simon Horman <horms@xxxxxxxxxxxx>
Subject: Re: [Xen-ia64-devel] Re: [patch 5/5] IA64: Kexec: Use a separate RID for EFI
From: tgingold@xxxxxxx
Date: Tue, 23 Oct 2007 14:04:21 +0200
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 23 Oct 2007 04:04:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071023023656.GC20704@xxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20071022024930.186104656@xxxxxxxxxxxx> <20071022025743.420129509@xxxxxxxxxxxx> <1193081609.6559.44.camel@lappy> <20071023014709.GC25940%yamahata@xxxxxxxxxxxxx> <20071023023656.GC20704@xxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Internet Messaging Program (IMP) 3.2.5
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