Re: [Xen-devel] [PATCH RFC 4/4] hvmloader:ovmf: setup E820 map

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Nov 20, 2013 at 11:51:50AM +0000, Ian Campbell wrote:
> On Wed, 2013-11-20 at 11:49 +0000, Wei Liu wrote:
> > On Wed, Nov 20, 2013 at 10:07:08AM +0000, Ian Campbell wrote:
> > > On Tue, 2013-11-19 at 18:01 +0000, Wei Liu wrote:
> > > > On Tue, Nov 19, 2013 at 05:56:28PM +0000, Ian Campbell wrote:
> > > > > On Fri, 2013-11-15 at 15:59 +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);
> > > > > > +    info->e820 = (uint32_t)e820;
> > > > > > +
> > > > > > +    /* OVMF doesn't load bios image below 0x100000 */
> > > > > > +    info->e820_nr = build_e820_table(e820, 0, 0xfffff);
> > > > > 
> > > > > I'm afraid I don't understand that comment, what is it referring too?
> > > > 
> > > > Looking at build_e820_table, the third parameter is base address of bios
> > > > image. We already load OVMF to higher address, we only need to make
> > > > build_e820_table happy. Probably we should modify build_e820_table
> > > > instead?
> > > 
> > > What about the stuff at LOWCHUNK_BEGIN?
> > > 
> > 
> > Only RAM in E820 map is revelant in OVMF, all other entries
> > are unparsed. And 0xA0000 - 0x1A0000 is automatically reserved in OVMF
> > code.
> 
> Regardless of what the OVMF code does I think the e820 table which
> hvmloader passes through should attempt to accurately describe what
> hvmloader has done.
> 

It is a bit confusing that SeaBIOS codes is relying on SeaBIOS to
reserve certain region. I just followed suit.

In any case, I think you make a good point. I will add that region to
E820 map.

Wei.

> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel