[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC][PATCH 4/5] tools:firmware:hvmloader: reserve RMRR mappings in e820
On 07/08/14 12:02, Tiejun Chen wrote: > We need to reserve all RMRR mappings in e820 to avoid any > potential guest memory conflict. > > Signed-off-by: Tiejun Chen <tiejun.chen@xxxxxxxxx> > --- > tools/firmware/hvmloader/e820.c | 14 ++++++++++++++ > tools/firmware/hvmloader/e820.h | 6 ++++++ > tools/firmware/hvmloader/util.c | 13 +++++++++++++ > tools/firmware/hvmloader/util.h | 1 + > 4 files changed, 34 insertions(+) > > diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c > index 2e05e93..8cf8c75 100644 > --- a/tools/firmware/hvmloader/e820.c > +++ b/tools/firmware/hvmloader/e820.c > @@ -74,6 +74,8 @@ int build_e820_table(struct e820entry *e820, > unsigned int bios_image_base) > { > unsigned int nr = 0; > + struct e820map *e820_rmrr_map; > + unsigned int i = 0; > > if ( !lowmem_reserved_base ) > lowmem_reserved_base = 0xA0000; > @@ -124,6 +126,18 @@ int build_e820_table(struct e820entry *e820, > e820[nr].type = E820_RAM; > nr++; > > + /* We'd better reserve RMRR mapping for each VM to avoid potential > + * memory conflict. > + */ > + e820_rmrr_map = get_rmrr_map_info(); > + for ( i = 0; i <= e820_rmrr_map->nr_map; i++ ) > + { > + e820[nr].addr = e820_rmrr_map->map[i].addr; > + e820[nr].size = e820_rmrr_map->map[i].size + 1; > + e820[nr].type = E820_RESERVED; > + nr++; > + } > + > /* > * Explicitly reserve space for special pages. > * This space starts at RESERVED_MEMBASE an extends to cover various > diff --git a/tools/firmware/hvmloader/e820.h b/tools/firmware/hvmloader/e820.h > index b2ead7f..ae4cc55 100644 > --- a/tools/firmware/hvmloader/e820.h > +++ b/tools/firmware/hvmloader/e820.h > @@ -15,6 +15,12 @@ struct e820entry { > uint32_t type; > } __attribute__((packed)); > > +#define E820MAX 128 > + > +struct e820map { > + int nr_map; This value should be unsigned. > + struct e820entry map[E820MAX]; > +}; > #endif /* __HVMLOADER_E820_H__ */ > > /* > diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c > index 80d822f..270700f 100644 > --- a/tools/firmware/hvmloader/util.c > +++ b/tools/firmware/hvmloader/util.c > @@ -766,6 +766,19 @@ struct shared_info *get_shared_info(void) > return shared_info; > } > > +struct e820map *get_rmrr_map_info(void) > +{ > + static struct e820map *e820_map = NULL; > + > + if ( e820_map != NULL ) > + return e820_map; > + > + if ( hypercall_memory_op(XENMEM_RMRR_memory_map, e820_map) != 0 ) > + BUG(); This instructs Xen to clobber the memory starting at 0, and works because HVMLoader is in protected, non-paging mode at this point. I don't think this is what you meant to do, and will repeatedly make the hypercall rather than caching the result. > + > + return e820_map; > +} > + > uint16_t get_cpu_mhz(void) > { > struct shared_info *shared_info = get_shared_info(); > diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h > index a70e4aa..26bfb8c 100644 > --- a/tools/firmware/hvmloader/util.h > +++ b/tools/firmware/hvmloader/util.h > @@ -236,6 +236,7 @@ unsigned long create_pir_tables(void); > void smp_initialise(void); > > #include "e820.h" > +struct e820map *get_rmrr_map_info(void); > int build_e820_table(struct e820entry *e820, > unsigned int lowmem_reserved_base, > unsigned int bios_image_base); _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |