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