|
[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 |