47 messages in com.xensource.lists.xen-ia64-develRe: [Xen-ia64-devel] Re: [patch 01/12...| From | Sent On | Attachments |
|---|---|---|
| Simon Horman | 22 Apr 2008 18:32 | .patch |
| Simon Horman | 22 Apr 2008 18:32 | .patch |
| Simon Horman | 22 Apr 2008 18:32 | .patch |
| Simon Horman | 22 Apr 2008 18:32 | |
| Simon Horman | 22 Apr 2008 18:32 | .patch |
| Simon Horman | 22 Apr 2008 18:32 | .patch |
| Simon Horman | 22 Apr 2008 18:32 | .patch |
| Simon Horman | 22 Apr 2008 18:32 | .patch |
| Simon Horman | 22 Apr 2008 18:33 | .patch |
| Simon Horman | 22 Apr 2008 18:33 | .patch |
| Simon Horman | 22 Apr 2008 18:33 | .patch |
| Simon Horman | 22 Apr 2008 18:33 | .patch |
| Simon Horman | 22 Apr 2008 18:33 | .patch |
| Simon Horman | 23 Apr 2008 16:03 | |
| Tristan Gingold | 23 Apr 2008 18:54 | |
| Simon Horman | 24 Apr 2008 03:03 | |
| Simon Horman | 24 Apr 2008 07:50 | |
| Alex Williamson | 24 Apr 2008 12:46 | |
| Simon Horman | 24 Apr 2008 18:15 | |
| Simon Horman | 24 Apr 2008 18:30 | |
| Isaku Yamahata | 24 Apr 2008 20:12 | |
| Simon Horman | 24 Apr 2008 20:42 | |
| Simon Horman | 24 Apr 2008 20:56 | |
| Tristan Gingold | 24 Apr 2008 21:25 | |
| Tristan Gingold | 24 Apr 2008 21:29 | |
| Simon Horman | 24 Apr 2008 21:35 | |
| Simon Horman | 24 Apr 2008 21:37 | |
| Simon Horman | 24 Apr 2008 22:34 | |
| Simon Horman | 24 Apr 2008 22:40 | |
| Isaku Yamahata | 24 Apr 2008 23:36 | |
| Simon Horman | 24 Apr 2008 23:47 | |
| Simon Horman | 27 Apr 2008 17:10 | |
| Simon Horman | 27 Apr 2008 18:07 | |
| Simon Horman | 28 Apr 2008 13:24 | |
| Simon Horman | 28 Apr 2008 13:25 | |
| Simon Horman | 28 Apr 2008 13:25 | |
| Simon Horman | 28 Apr 2008 13:31 | |
| Tristan Gingold | 28 Apr 2008 20:51 | |
| Alex Williamson | 29 Apr 2008 15:31 | |
| Simon Horman | 29 Apr 2008 16:04 | |
| Isaku Yamahata | 07 May 2008 01:30 | .patch |
| Simon Horman | 07 May 2008 15:57 | |
| Isaku Yamahata | 08 May 2008 00:14 | |
| Simon Horman | 08 May 2008 00:48 | |
| Isaku Yamahata | 13 Jul 2008 20:01 | |
| Isaku Yamahata | 13 Jul 2008 20:06 | |
| Isaku Yamahata | 13 Jul 2008 20:08 |
| Subject: | Re: [Xen-ia64-devel] Re: [patch 01/12] ia64: kexec: Define macros for EFI RID![]() |
|---|---|
| From: | Simon Horman (hor...@verge.net.au) |
| Date: | 04/24/2008 10:34:43 PM |
| List: | com.xensource.lists.xen-ia64-devel |
On Fri, Apr 25, 2008 at 02:38:15PM +1000, Simon Horman wrote:
On Fri, Apr 25, 2008 at 06:30:00AM +0200, Tristan Gingold wrote:
[...]
On Fri, Apr 25, 2008 at 06:25:37AM +0200, Tristan Gingold wrote:
On Fri, Apr 25, 2008 at 01:57:04PM +1000, Simon Horman wrote:
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 ?
After a minute, I don't think we need to choose an RID compatible with Linux, right ? If so, why not using simpler RIDs in head.S as well as a simpler XEN_EFI_RID ?
That is true, the RID does not need to be compatible with Linux. I'll look into your idea of using something in head.S.
(To be honnest, this could be fixed after - I just think the comment is a little bit misleading).
Sorry about that. When I wrote that comment I was somewhat confused myself. I intended it to be more of a discussion point than a description of what is going on.
Below is an updated version of the description. I think that the key point is that using a RID from the 0th small-block will protect memory inserted using that RID from access by domains.
The rest is just an explanation of how I chose an RID in the 0th small-block.
-- Horms
/* * According to xen/arch/ia64/xen/regionreg.c the RID space is broken up * into large-blocks. Each block belongs to a domain, except 0th block, * which is broken up into small-blocks. The small-blocks are used for * metaphysical mappings, again one per domain, except for the 0th * small-block which is unused other than very early on in the * hypervisor boot. * * By default each large-block is 18 bits wide, which is also the minimum * allowed width for a block. Each small-block is by default 1/64 the width * of a large-block, which is the maximum division allowed. In other words * each small-block is at least 12 bits wide. * * The portion of the 0th small-block that is used early on during * the hypervisor boot relates to IA64_REGION_ID_KERNEL, which is * used to form an RID using the following scheme which seems to be * have been inherited from Linux: * * a: bits 0-2: Region Number (0-7) * b: 3-N: IA64_REGION_ID_KERNEL (0) * c: N-23: reserved (0) * * N is defined by the platform. * * For EFI we use the following RID: * * a: bits 0-2: Region Number (0-7) * e: bits 3-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 only using 4 bits of RID * space, so it shouldn't have any chance of running into an adjacent * small-block since small-blocks are at least 12 bits wide. * * 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 thus 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. * * For reference, the RID is used to produce the value inserted * in to a region register in the following way: * * A: bit 0: VHPT (0 = off, 1 = on) * B: bit 1: reserved (0) * C: bits 2-7: log 2 page_size * D: bits 8-N: RID * E: bits N-53: reserved (0) */
_______________________________________________ Xen-ia64-devel mailing list Xen-...@lists.xensource.com http://lists.xensource.com/xen-ia64-devel





.patch