[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 4/4] hvmloader:ovmf: setup E820 map
On Tue, 2013-11-19 at 20:05 +0000, Wei Liu wrote: > On Tue, Nov 19, 2013 at 02:56:31PM -0500, Konrad Rzeszutek Wilk wrote: > > On Fri, Nov 15, 2013 at 03:59:25PM +0000, Wei Liu wrote: > > > E820 map will be used by OVMF to create memory map. > > > > > > Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> > > > --- > > > tools/firmware/hvmloader/ovmf.c | 13 ++++++++++++- > > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > > > diff --git a/tools/firmware/hvmloader/ovmf.c > > > b/tools/firmware/hvmloader/ovmf.c > > > index c253083..52ccd0d 100644 > > > --- a/tools/firmware/hvmloader/ovmf.c > > > +++ b/tools/firmware/hvmloader/ovmf.c > > > @@ -128,6 +128,17 @@ static void ovmf_create_smbios_tables(void) > > > SMBIOS_PHYSICAL_END); > > > } > > > > > > +static void ovmf_setup_e820(void) > > > +{ > > > + struct ovmf_info *info = (void *)OVMF_INFO_PHYSICAL_ADDRESS; > > > + struct e820entry *e820 = scratch_alloc(sizeof(struct e820entry)*16, > > > 0); > > > > 16? Why not 128 (the default in most kernels)? > > Aye, sir. :-) This is an internal datastructure which hvmloader generates an e820 into, it only needs to be large enough to hold whatever hvmloader currently generates and not the theoretical maximum. I think 16 is more than sufficient for now. In fact by looking at build_e820_table it seems that it currently generates at most 9 entries. If you really wanted to change something here then either expose a suitable table size from e820.[ch] (e.g. as a #define) to {seabios,ovmf}.c or pass in the allocated size and validate it against nr in build_e820_table. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |