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. _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios