On Wed, Jul 25, 2012 at 01:44:20PM +0200, Idwer Vollering wrote:
Unmodified tree, at 9d6bac1d32b72cdf7c0ad009c1371a2e69084de3
At a guess, the iasl warnings are confusing the
acpi_extract_preprocess.py script. What version of iasl do you have?
-Kevin
2012/7/25 Kevin O'Connor ke...@koconnor.net:
On Wed, Jul 25, 2012 at 01:44:20PM +0200, Idwer Vollering wrote:
Unmodified tree, at 9d6bac1d32b72cdf7c0ad009c1371a2e69084de3
At a guess, the iasl warnings are confusing the
acpi_extract_preprocess.py script. What version of iasl do you have?
The
On Fri, Jul 20, 2012 at 05:00:25PM -0300, Eduardo Habkost wrote:
Hi,
While working at the CPU index vs APIC ID changes, I stumbled upon
another not-very-well-defined interface between SeaBIOS and QEMU, and I
would like to clarify the semantics and constraints of some FW_CFG
entries.
On Mon, Jul 23, 2012 at 03:20:14PM +0300, Gleb Natapov wrote:
On Fri, Jul 20, 2012 at 02:04:50PM -0300, Eduardo Habkost wrote:
Extract Local APIC IDs directly from the CPUs, and instead of check for
i CountCPUs, check if the APIC ID was present on boot, when building
ACPI tables and the
Changes v2 - v3:
- Report I/O APIC ID = 0 on MP-table, too
Changes v1 - v2:
- Patch 1/2: cosmetic whitespace change
- Patch 2/2: use size suffixes on asm instructions on smp.c
- New patch descriptions
Eduardo Habkost (2):
report real I/O APIC ID (0) on MADT and MP-table (v3)
allow CPUs
When resetting an I/O APIC, its ID is set to 0, and SeaBIOS doesn't
change it, so report it correctly on the ACPI MADT table and MP-table.
Some hardware may require the BIOS to initialize I/O APIC ID to an
unique value, but SeaBIOS doesn't do that. This patch at least makes the
tables reflect
Extract Local APIC IDs directly from the CPUs, and instead of check for
i CountCPUs, check if the APIC ID was present on boot, when building
ACPI tables and the MP-Table.
This keeps ACPI Processor ID == APIC ID, but allows the
hardware-SeaBIOS interface be completely APIC-ID based and not depend
On Wed, Jul 25, 2012 at 02:45:31PM +0200, Idwer Vollering wrote:
2012/7/25 Kevin O'Connor ke...@koconnor.net:
On Wed, Jul 25, 2012 at 01:44:20PM +0200, Idwer Vollering wrote:
Unmodified tree, at 9d6bac1d32b72cdf7c0ad009c1371a2e69084de3
At a guess, the iasl warnings are confusing the