[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.