We had an earlier version of our patch that just altered the e820
table, but we were concerned about the code complexity needed to do that (the
existing Xen e820 fns aren’t sufficient for this). Here is the change
that we would need to add—do you prefer this:
diff -r dbac9ee4d761 xen/arch/x86/e820.c
--- a/xen/arch/x86/e820.c Mon
Sep 08 16:02:13 2008 +0100
+++ b/xen/arch/x86/e820.c Sat
Nov 22 02:04:51 2008 +0800
@@ -373,11 +373,13 @@ static void __init
machine_specific_memo
reserve_dmi_region();
}
-/* Reserve RAM area (@s,@e) in the specified e820
map. */
-int __init reserve_e820_ram(struct e820map *e820,
uint64_t s, uint64_t e)
+static int reserve_e820(uint32_t type, struct
e820map *e820,
+
uint64_t s, uint64_t e, uint32_t t)
{
uint64_t rs = 0, re = 0;
- int i;
+ int i, remove;
+
+ remove = (type == t);
for ( i = 0; i <
e820->nr_map; i++ )
{
@@ -388,55 +390,131 @@ int __init
reserve_e820_ram(struct e820m
break;
}
- if ( (i == e820->nr_map) ||
(e820->map[i].type != E820_RAM) )
+ if ( (i == e820->nr_map) ||
(e820->map[i].type != type) )
return 0;
if ( (s == rs) &&
(e == re) )
{
/*
Complete excision. */
-
memmove(&e820->map[i], &e820->map[i+1],
-
(e820->nr_map-i-1) * sizeof(e820->map[0]));
-
e820->nr_map--;
+ if
(remove)
+ {
+
memmove(&e820->map[i], &e820->map[i+1],
+
(e820->nr_map-i-1) * sizeof(e820->map[0]));
+
e820->nr_map--;
+ }
+ else
+
e820->map[i].type = t;
}
else if ( s == rs )
{
- /*
Truncate start. */
+ /* If
not remove, split it in two, or else, truncate start. */
+ if
(!remove)
+ {
+
if ( e820->nr_map+1 > ARRAY_SIZE(e820->map) )
+
{
+
printk("e820 overflow\n");
+
return 0;
+
}
+
memmove(&e820->map[i+1], &e820->map[i],
+
(e820->nr_map-i) * sizeof(e820->map[0]));
+
e820->nr_map++;
+
e820->map[i].addr = s;
+
e820->map[i].size = e - s;
+
e820->map[i].type = t;
+
i++;
+ }
e820->map[i].addr += e - s;
e820->map[i].size -= e - s;
}
else if ( e == re )
{
- /*
Truncate end. */
-
e820->map[i].size -= e - s;
- }
- else if ( e820->nr_map <
ARRAY_SIZE(e820->map) )
- {
- /* Split
in two. */
-
memmove(&e820->map[i+1], &e820->map[i],
-
(e820->nr_map-i) * sizeof(e820->map[0]));
-
e820->nr_map++;
-
e820->map[i].size = s - rs;
- i++;
-
e820->map[i].addr = e;
-
e820->map[i].size = re - e;
+ /* If
not remove, split it in two, or else, truncate end. */
+ if
(!remove)
+ {
+
if ( e820->nr_map+1 > ARRAY_SIZE(e820->map) )
+
{
+
printk("e820 overflow\n");
+
return 0;
+
}
+
memmove(&e820->map[i+1], &e820->map[i],
+
(e820->nr_map-i) * sizeof(e820->map[0]));
+
e820->nr_map++;
+
e820->map[i].size -= e - s;
+
i++;
+
e820->map[i].addr = s;
+
e820->map[i].size = e - s;
+
e820->map[i].type = t;
+ }
+ else
+
e820->map[i].size -= e - s;
}
else
{
- /*
e820map is at maximum size. We have to leak some space. */
- if ( (s
- rs) > (re - e) )
+ /* If
not remove, split in three, or else, split in two. */
+ if
(!remove)
{
-
printk("e820 overflow: leaking RAM
%"PRIx64"-%"PRIx64"\n", e, re);
+
if ( e820->nr_map+2 > ARRAY_SIZE(e820->map) )
+
{
+
printk("e820 overflow\n");
+
return 0;
+
}
+
memmove(&e820->map[i+2], &e820->map[i],
+
(e820->nr_map-i) * sizeof(e820->map[0]));
+
e820->nr_map += 2;
e820->map[i].size = s - rs;
+
i++;
+
e820->map[i].addr = s;
+
e820->map[i].size = e - s;
+
e820->map[i].type = t;
+
i++;
+
e820->map[i].addr = e;
+
e820->map[i].size = re - e;
}
else
{
-
printk("e820 overflow: leaking RAM
%"PRIx64"-%"PRIx64"\n", rs, s);
-
e820->map[i].addr = e;
-
e820->map[i].size = re - e;
+
if ( e820->nr_map < ARRAY_SIZE(e820->map) )
+
{
+
memmove(&e820->map[i+1], &e820->map[i],
+
(e820->nr_map-i) * sizeof(e820->map[0]));
+
e820->nr_map++;
+
e820->map[i].size = s - rs;
+
i++;
+
e820->map[i].addr = e;
+
e820->map[i].size = re - e;
+
}
+
else
+
{
+
/* e820map is at maximum size. We have to leak some space. */
+ if
( (s - rs) > (re - e) )
+
{
+
printk("e820 overflow: leaking RAM
%"PRIx64"-%"PRIx64"\n",
+
e, re);
+
e820->map[i].size = s - rs;
+
}
+
else
+
{
+
printk("e820 overflow: leaking RAM
%"PRIx64"-%"PRIx64"\n",
+
rs, s);
+
e820->map[i].addr = e;
+
e820->map[i].size = re - e;
+
}
+
}
}
}
return 1;
+}
+
+/* Reserve RAM area (@s,@e) in the specified e820
map. */
+int __init reserve_e820_ram(struct e820map *e820,
uint64_t s, uint64_t e)
+{
+ return reserve_e820(E820_RAM,
e820, s, e, E820_RAM);
+}
+
+/* Reserve RESERVE area (@s, @e) as UNUSABLE in the
specified e820 map. */
+int reserve_e820_reserved(struct e820map *e820,
uint64_t s, uint64_t e)
+{
+ return
reserve_e820(E820_RESERVED, e820, s, e, E820_UNUSABLE);
}
unsigned long __init init_e820(
From: Keir Fraser
[mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Tuesday, January 20, 2009 12:57 AM
To: Cihula, Joseph; xen-devel@xxxxxxxxxxxxxxxxxxx;
xense-devel@xxxxxxxxxxxxxxxxxxx
Cc: Wang, Shane
Subject: Re: [PATCH] txt: 2/6 - explicitly protect TXT addr ranges from
dom0
Xen tracks protected memory regions in its
private e820 structure. If tboot is no longer marking E820_UNUSABLE in e820,
then have Xen manually add the regions to its private e820. Then you
won’t need your new ad hoc structure plus needing to process that new
structure in various places.
-- Keir
On 20/01/2009 05:49, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> wrote:
tboot
no longer marks the TXT heap/SINIT/private config space as E820_UNUSABLE in the
e820 table, so Xen must explicitly disallow those regions from dom0.
Signed-off-by: Shane Wang <shane.wang@xxxxxxxxx>
Signed-off-by: Joseph Cihula <joseph.cihula@xxxxxxxxx>
