https://bugzilla.kernel.org/show_bug.cgi?id=97141
--- Comment #13 from Lv Zheng <[email protected]> --- (In reply to Rafael J. Wysocki from comment #12) > (In reply to Lv Zheng from comment #8) > > I'm OK with BGRT which is a data table, but for TAD which comes from a > > definition block table, I do have concerns... > > > > At this early boot time, PCI configuration space may not be accessible. > > Thus some module level code in the ACPI definition block table is also not > > executable. > > Invoking acpi_load_tables() so early causes a very strange software scheme > > in ACPICA. > > ACPICA interpreter has to execute only special AML code and ignore all > > module level code in this early stage and at a late stage, re-execute the > > module level code. This makes ACPICA interpreter implementation very dirty. > > I'm not sure I understand your point correctly. > > Do you have any specific examples of what may go wrong as a result of this? For both the code inside of a Method and the code at the module level for the table (do not belong to any method), AML grammer for them defined in the spec is TermList. So they should be interpreted in the same style - both table loading and method execution should work in the same way. I've tried and it worked here: http://sourceforge.net/p/sdfirm/code/ci/master/tree/kernel/acpi/acpi_interp.c Both acpi_interpret_table() and acpi_evaluate_object() can invoke acpi_interpret_aml() with same arguments. But ACPICA is currently not implemented in this way. In acpi_load_tables(), only limitted opcodes (named object creation opcodes) are executed in a 2-pass parsing (load_pass_1 and load_pass_2) and many opcodes in the "If", "Else", .. packages are just linked together (acpi_ps_link_module_code()). This happens during the early stage (acpi_early_init()). At a later stage (acpi_bus_init()), such module level code will be executed (acpi_ns_exec_module_code_list()). The code for module level execution is nasty, it hacks "\" from a device to a method in order for the executer code to work and hacks it back after completing the module level execution. While for method invocation, it is currently executed only in 1-pass parsing (execute_pass). For the above 2-load-pass parsing implementation, only limitted opcodes can be supported during table loading. And the 2-load-pass parsing caused some known compliance issues. For example, if the load-pass-1 failed at a point, then the namespace node created before this point will be successfully created, but since the load-pass-2 is aborted, such namespace nodes will be left without operand objects attached, they will be non-calulatable objects... So far no BIOS issues reported on Windows around such broken tables. This links to the dicussion of this nasty code issue: http://bugs.acpica.org/show_bug.cgi?id=963 I was thinking the reason for current implementation is due to the all-in-one code base for both the iasl disassembler and the in-kernel interpreter. But it seems Linux also has something to do with this, it is hard to move acpi_load_tables() to a late stage and merges it with the module level execution into the big execute-pass parsing. Thanks and best regards -Lv -- You are receiving this mail because: You are watching the assignee of the bug. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
