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