On Tue, Oct 23, 2007 at 10:47:09AM +0900, Isaku Yamahata wrote:
> On Mon, Oct 22, 2007 at 01:33:29PM -0600, Alex Williamson wrote:
> > On Mon, 2007-10-22 at 11:49 +0900, Simon Horman wrote:
> > > The patch does seem to work, in the sense that the EFI mappings work.
> > > I have not stress tested it to see if domains can still do nefarious
> > > things. I would appreciate a review of this.
> >
> > Hi Simon,
> >
> > This generally looks ok, but I'd like to get an ack from Isaku and
> > Tristan.
>
> After taking a rough look for it, it looks basically O.K.
> Just for some minor comments at this moment,
> - Good work!
> - EFI region detection is done by !guest_mode() and addrees checking.
> It would be safer to add check rid==EFI_RID. (minor issue)
I think that right now I am doing both checks. First the guest_mode()
one then the RID one. But I think we can get rid of the guest_mode()
check and just do the RID one earlier on. I'll make this so.
> - It is somewhat unclear (at least to me) that where EFI_RID comes from.
> Please add a comment. (minor issue)
> Possibly it might be necessary to avlid rid collisoin.
> I had taken only a rough look so I might be wrong.
> At any rate it would be easily worked around and someone
> (Simon-san or me or anyone else who want to) can address it
> independently.
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.
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.
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.
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
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().
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.
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.
--
宝曼 西門 (ホウマン・サイモン) | Simon Horman (Horms)
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home