[SeaBIOS] [PATCH 2/2] accept MADT over fw_cfg
Michael S. Tsirkin
mst at redhat.com
Tue Apr 23 10:49:57 CEST 2013
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.
And of course newer ACPI has lots of other pointer quirks,
I assume you are aware of this.
> 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?
I wanted to handle checksums and pointers in a generic fashion,
and allocation rules in a table specific version
(since I only found two such examples in all of the spec:
FACS and RSDP). It's not hard to add generic handlers for these two,
and it's not much more code. You think it's preferable then?
More information about the SeaBIOS