qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 06/14] i386: add bios linker/loader


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v3 06/14] i386: add bios linker/loader
Date: Sun, 28 Jul 2013 11:08:26 +0300

On Fri, Jul 26, 2013 at 11:42:45AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> Hacked up coreboot support to verify the interface.
> 
> > +        /*
> > +         * COMMAND_ALLOCATE - allocate a table from @alloc_file
> > +         * subject to @alloc_align alignment (must be power of 2)
> > +         * and @alloc_zone (can be HIGH or FSEG) requirements.
> > +         *
> > +         * Must appear exactly once for each file, and before
> > +         * this file is referenced by any other command.
> > +         */
> 
> Do we need alloc_zone?
> 
> Rules are simple: rsdp goes to fseg, everything else to high, correct?

Yes but I prefer marking it explicitly at link time and avoid hard-coding
things in the bios, so that whoever allocates memory can go just by
linker rules and not poke at tables themselves.

> Both seabios and coreboot handle that by first placing *all* acpi tables
> in high memory, then go place a rsdp copy in fseg.

No, what happens is we put everything in tmp memory, then
copy where appropriately.

> > +        /*
> > +         * COMMAND_ADD_POINTER - patch the table (originating from
> > +         * @dest_file) at @pointer_offset, by adding a pointer to the table
> > +         * originating from @src_file. 1,2,4 or 8 byte unsigned
> > +         * addition is used depending on @pointer_size.
> > +         */
> 
> Do we need pointer_size?
> 
> Current tables use 4 bytes only.
> 
> 1+2 bytes is pointless, the src_file address will be big enougth that it
> doesn't fit into one or two bytes, so I doubt they will ever be used.
> 
> 8 bytes would only be used when placing acpi tables above 4g.  Is that
> something expected to happen?

Yes, the spec allows 64 bit pointers.

> If not 4 bytes is enough, even for 8 byte
> pointers as the 4 high bytes would be zero no matter what.
> 
> cheers,
>   Gerd



reply via email to

[Prev in Thread] Current Thread [Next in Thread]