Re: [Xen-devel] Linux as 32-bit Dom0?

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 11/22/2017 09:40 AM, Juergen Gross wrote:
> On 22/11/17 15:05, Jan Beulich wrote:
>> Jürgen, Boris,
>>
>> am I trying something that's not allowed, but selectable via Kconfig?
>> On system with multiple IO-APICs (I assume that's what triggers the
>> problem) I get
>>
>> Kernel panic - not syncing: Max apic_id exceeded!
> Generally I don't think 32 bit dom0 is forbidden, but rarely used. I
> wouldn't be too sad in case we'd decide to drop that support. ;-)
>
> Can you please be a little bit more specific?
>
> How many IOAPICs? From the code I guess this is an INTEL system with not
> too recent IOAPIC versions (<0x14)?
>
> Having a little bit more of the boot log might help, too.


I just booted a 3-IOAPIC Intel box with a 32-bit 4.13 kernel.

(well, it actually didn't quite boot as it hang somewhere further down
the line, so that's a problem).

I do see

...
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
[    0.000000] IOAPIC[0]: apic_id 0 already used, trying 1
[    0.000000] IOAPIC[0]: Unable to change apic_id!
[    0.000000] IOAPIC[0]: apic_id 255, version 32, address 0xfec00000,
GSI 0-23
[    0.000000] IOAPIC[1]: apic_id 1 already used, trying 3
[    0.000000] IOAPIC[1]: Unable to change apic_id!
[    0.000000] IOAPIC[1]: apic_id 255, version 32, address 0xfec3f000,
GSI 24-47
[    0.000000] IOAPIC[2]: apic_id 2 already used, trying 5
[    0.000000] IOAPIC[2]: Unable to change apic_id!
[    0.000000] IOAPIC[2]: apic_id 255, version 32, address 0xfec7f000,
GSI 48-71


-boris



>
>
> Juergen
>
>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.1-2017-11-21-xen0 #6
>> Hardware name: ...
>> Call Trace:
>>  ? show_stack+0x20/0x50
>>  ? dump_stack+0x7e/0xc0
>>  ? panic+0x99/0x220
>>  ? io_apic_get_unique_id+0x207/0x210
>>  ? __raw_callee_save_xen_restore_fl+0x6/0x8
>>  ? xen_flush_tlb_single+0x6f/0x80
>>  ? set_pte_vaddr+0xef/0x110
>>  ? xen_io_apic_read+0x36/0x90
>>  ? mp_register_ioapic+0x2b7/0x410
>>  ? acpi_os_map_iomem+0x14d/0x210
>>  ? acpi_parse_ioapic+0x6b/0x6f
>>  ? acpi_parse_entries_array+0xa1/0x16d
>>  ? acpi_tb_get_table+0x95/0x9d
>>  ? acpi_ut_release_mutex+0x109/0x10e
>>  ? acpi_table_parse_entries_array+0x98/0xa8
>>  ? acpi_table_parse_entries+0x30/0x35
>>  ? acpi_boot_init+0x65/0x65
>>  ? acpi_table_parse_madt+0x1b/0x1f
>>  ? acpi_boot_init+0x65/0x65
>>  ? acpi_parse_madt_ioapic_entries+0x4a/0x119
>>  ? mutex_lock+0x8/0x30
>>  ? acpi_process_madt+0xbe/0x105
>>  ? acpi_boot_init+0x3d/0x65
>>  ? setup_arch+0x67a/0x83f
>>  ? 0xc1000000
>>  ? start_kernel+0x46/0x361
>>  ? x86_early_init_platform_quirks+0x4d/0x90
>>  ? i386_start_kernel+0x22/0x88
>>  ? xen_start_kernel+0x453/0x639
>> (XEN) Hardware Dom0 crashed: 'noreboot' set - not rebooting.
>>
>> I admit I have a few custom patches in that tree, but I'm reasonably
>> certain that none of them comes even close to having such an effect.
>>
>> Jan
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel