[SeaBIOS] [PATCH 2/2] accept MADT over fw_cfg

[Michael S. Tsirkin]

On Tue, May 07, 2013 at 10:37:28PM +0300, Gleb Natapov wrote:
> On Tue, May 07, 2013 at 10:33:17PM +0300, Michael S. Tsirkin wrote:
> > On Tue, May 07, 2013 at 10:26:34PM +0300, Gleb Natapov wrote:
> > > On Tue, May 07, 2013 at 09:54:33PM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, May 07, 2013 at 09:07:04PM +0300, Gleb Natapov wrote:
> > > > > On Wed, Apr 24, 2013 at 11:09:16AM +0300, Michael S. Tsirkin wrote:
> > > > > > On Tue, Apr 23, 2013 at 08:23:44PM +0300, Michael S. Tsirkin wrote:
> > > > > > > On Mon, Apr 22, 2013 at 08:38:58PM -0400, Kevin O'Connor wrote:
> > > > > > > > On Mon, Apr 22, 2013 at 10:03:01AM +0300, Michael S. Tsirkin wrote:
> > > > > > > > > On Sun, Apr 21, 2013 at 08:39:41PM -0400, Kevin O'Connor wrote:
> > > > > > > > > > On Sun, Apr 21, 2013 at 11:41:48PM +0300, Michael S. Tsirkin wrote:
> > > > > > > > > > > Okay I'm pretty close to posting some patches
> > > > > > > > > > > that advance this project further, but wanted to
> > > > > > > > > > > check something beforehand: there are several tables
> > > > > > > > > > > that point to other tables (for example: FADT points
> > > > > > > > > > > to DSDT). What I did is provide a list of fixups
> > > > > > > > > > > such that bios can patch in pointers without
> > > > > > > > > > > any need to understand what's what.
> > > > > > > > > > > Thoughts?
> > > > > > > > > > 
> > > > > > > > > > For the RSDP, RSDT, and FADT I think SeaBIOS should just update those
> > > > > > > > > > tables to set the pointers within them and then recalculate the
> > > > > > > > > > checksum.  I don't think anything complex is needed - it's easy for
> > > > > > > > > > SeaBIOS to recognize those special tables and modify them.
> > > > > > > > > 
> > > > > > > > > True, that's simple enough.  My worry is we can add more such tables.
> > > > > > > > > For example, we can decide to switch to XSDT in the future.
> > > > > > > > 
> > > > > > > > I know of the following quirks that would have to be handled:
> > > > > > > > 
> > > > > > > > 1 - the RSDP must be in the f-segment (where as all other tables can
> > > > > > > > go into "high" memory).
> > > > > > > > 
> > > > > > > > 2 - the RSDP has a checksum in a different location from the other
> > > > > > > > tables and (with an XSDT) it can have two checksums.
> > > > > > > > 
> > > > > > > > 3 - the RSDP has a pointer to the RSDT (and to the XSDT if present).
> > > > > > > > 
> > > > > > > > 4 - the RSDT (and XSDT if present) has pointers to all the other
> > > > > > > > tables (except RSDP, RSDT, DSDT, and FACS).  The FADT pointer must be
> > > > > > > > first in the list.
> > > > > > > > 
> > > > > > > > 5 - the FADT table has pointers to DSDT and FACS.
> > > > > > > > 
> > > > > > > > 6 - the FACS table must be 64 byte aligned.
> > > > > > > > 
> > > > > > > > So, will a generic scheme really be able to handle all of the above
> > > > > > > > quirks, or will we just be mixing some hardcoded quirks with some
> > > > > > > > generic quirks?  And, will the code to handle the above quirks in a
> > > > > > > > generic fashion be of a higher complexity than simply hard-coding it?
> > > > > > > > 
> > > > > > > > -Kevin
> > > > > > > 
> > > > > > > -->
> > > > > > > 
> > > > > > > So here's an implementation for align and FSEG.
> > > > > > > Not a big deal as you see.
> > > > > > > 
> > > > > > > I really have doubts about it however: BIOS still must be able to parse
> > > > > > > get the resume vector in FACS in order to support wakeup, right? So this
> > > > > > > means that we need to be able to parse RSDP and FACT.  These happen to
> > > > > > > be the only things that need anything not addressed by ADD and SUB so
> > > > > > > ... maybe a couple of hardcoded quirks just to allocate these correctly
> > > > > > > is cleaner.
> > > > > > 
> > > > > > Heh, it's actually pretty easy: let's just ask qemu
> > > > > > to give us the address of the resume vector
> > > > > > in a file with a pre-defined name.
> > > > > > Linker can patch table offset there in the
> > > > > > regular way.
> > > > > > 
> > > > > Seabios can find resume vector address the same way OSPM does: by following
> > > > > pointers in memory.
> > > > 
> > > > Yes, that's what we do now.
> > > > 
> > > Good.
> > > 
> > > > > What QEMU has to do with it?
> > > > 
> > > > The paragraphs above explain the connection.
> > > > 
> > > Do not see any explanation anywhere.
> > 
> > Maybe I don't understand your question then.
> > What exactly would you like to know?
> > 
> My question is why would you "ask qemu to give us the address of the
> resume vector in a file with a pre-defined name". But since you do not
> do that in your patches I think we are in agreement that this is not
> needed.
> 
> --
> 			Gleb.

Generally I'd rather not write summaries of old discussions.
But just this once.

Not strictly. The thread discussed what should we do with FACS
which has alignment requirements: let bios detect FACS
and align, or have qemu tell bios "align this table at X".
If we do later, it appeared we still need knowledge
of the FACS layout in bios, for resume, so why try to be generic?
Unless, we add another channel to tell bios where resume vector
within FACS is.

For now, I plan to keep it simple and parse FACS in bios.

Now let's stop this thread, ok? It's from Apr 24, let it pass.

-- 
MST