Re: Crash in acpi_ps_peek_opcode when booting kernel 3.19 as Xen dom0

[Stefan Bader <stefan.bader@canonical.com>]

[-- Attachment #1.1: Type: text/plain, Size: 8855 bytes --]

On 05.02.2015 15:33, Stefan Bader wrote:
> While experimenting/testing various kernel versions I discovered that trying to
> boot a Haswell based hosts will always crash when booting as Xen dom0
> (Xen-4.4.1). The same crash happens since v3.19-rc1 and still does happen with
> v3.19-rc7. A bare metal boot is having no issues and also an Opteron based host
> is having no issues (dom0 and bare metal).
> Could be a table that the other host does not have and since its only happening
> in dom0 maybe some cpu capability that needs to be passed on?

I think I may have some more data here. I tried some patches which Juergen sent
me, but those were not changing much. I found that the problem is related on
that host to the use of dom0_mem= and may be a crash like below or a hang or
"weird state" in general.
When not using dom0_mem, I can boot with a 3.19 kernel, otherwise (trying 512M
and 1G) there is trouble. What is special about this host is that is has more
"holes" than the other machine I usually use.

(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009a400 (usable)
(XEN)  000000000009a400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
       The first hole is common
(XEN)  0000000000100000 - 0000000030a48000 (usable)
(XEN)  0000000030a48000 - 0000000030a49000 (reserved)
(XEN)  0000000030a49000 - 00000000a27f4000 (usable)
       But then normally there is only one usable area up to
       around ACPI_NVS
(XEN)  00000000a27f4000 - 00000000a2ab4000 (reserved)
(XEN)  00000000a2ab4000 - 00000000a2fb4000 (ACPI NVS)
(XEN)  00000000a2fb4000 - 00000000a2feb000 (ACPI data)
(XEN)  00000000a2feb000 - 00000000a3000000 (usable)
(XEN)  00000000a3000000 - 00000000afa00000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed00000 - 00000000fed04000 (reserved)
(XEN)  00000000fed10000 - 00000000fed1a000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fed84000 - 00000000fed85000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffc00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000024e600000 (usable)
       Also after ACPI data there is some usable, and then another
       hole (area) which is unuasual.

So I added a bit more debug printk's: Here a boot with dom0_mem=512M:max=512M:

[    0.000000] SMB: remap 154(0x9A)-256(0x100) -> 131072(0x20000)
               ==> 0x09A000-0x100000 -> 0x20000000 (@512M+)
               ==> 0x09A000-0x09A3FF was usable but partial

The first hole is supposed to be remapped as it is below the 512M which are in
the initial MFN list. I suppose this works but Juergen, I really would love to
understand how and I am not sure I grasp things. To me it looks like the remap
info is stored in the memory area to be mapped... which is reserved(?!)

I think the problem comes from these other holes (which are beyond 512M). When
not using dom0_mem those are remapped (like the first one), while with the clamp
they supposedly should be identity mapped...

[    0.000000] SMB: prange id 199240(0x30A48) - 199241(0x30A49)
               ==> 0x30A48000(~778M)
[    0.000000] SMB: prange id 665588(0xA27F4) - 667627(0xA2FEB)
               ==> 0xA27F4000(~2599M)
[    0.000000] SMB: prange id 667648(0xA3000) - 1048576(0x100000)
               ==> 0xA3000000(~2608M)-0x100000000(=4G) id mapped
[    0.000000] Released 0 page(s)
[    0.000000] Remapped 102 page(s)

So here is xen_set_identity_and_remap_chunk():

...
while (i < n) {
  ...
  /* Do not remap pages beyond the current allocation */
  if (cur_pfn >= nr_pages) {
    /* Identity map remaining pages */
    set_phys_range_identity(cur_pfn, cur_pfn + size);
    break;
  }
  ...

Now, I think the call to set_phys_range_identity() is really doing nothing
because nr_pages really is the same (or mostly beside of an 512 alignment) as
xen_p2m_size, so it just returns 0.

  ...
  /*
   * If the PFNs are currently mapped, the VA mapping also needs
   * to be updated to be 1:1.
   */
  for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
          (void)HYPERVISOR_update_va_mapping(
                  (unsigned long)__va(pfn << PAGE_SHIFT),
                  mfn_pte(pfn, PAGE_KERNEL_IO), 0);

I cannot make my head up about this one. Before this all changed, there was code
that resembled this loop but was rather clearing the mapping (except for a range
below 1M). Ok, that was done then in a different order which set identity
mapping after...

My feeling is that the problem comes from assuming identity mapping for holes
after the initial mapping. I might miss something but I cannot really see where
this could be recovered.

-Stefan
> 
> [    2.108038] ACPI: Core revision 20141107
> [    2.108153] ACPI Warning: Unsupported module-level executable opcode 0x91 at
> table offset 0x002B (20141107/psloop-225)
> [    2.108264] ACPI Warning: Unsupported module-level executable opcode 0x91 at
> table offset 0x0033 (20141107/psloop-225)
> [    2.108375] ACPI Warning: Unsupported module-level executable opcode 0x95 at
> table offset 0x0038 (20141107/psloop-225)
> [    2.108489] ACPI Warning: Unsupported module-level executable opcode 0x95 at
> table offset 0x0041 (20141107/psloop-225)
> [    2.108613] ACPI Warning: Unsupported module-level executable opcode 0x7D at
> table offset 0x040D (20141107/psloop-225)
> [    2.108751] BUG: unable to handle kernel paging request at ffffc90000ee74e0
> [    2.108835] IP: [<ffffffff814573db>] acpi_ps_peek_opcode+0xd/0x1f
> [    2.108902] PGD 1f4be067 PUD 1f4bd067 PMD 1488f067 PTE 0
> [    2.109018] Oops: 0000 [#1] SMP
> [    2.109094] Modules linked in:
> [    2.109153] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-031900rc7-generi
> c #201502020035
> [    2.109220] Hardware name: Intel Corporation Shark Bay Client platform/Flathe
> ad Creek Crb, BIOS HSWLPTU1.86C.0109.R03.1301282055 01/28/2013
> [    2.109295] task: ffffffff81c1c500 ti: ffffffff81c00000 task.ti: ffffffff81c0
> 0000
> [    2.109360] RIP: e030:[<ffffffff814573db>]  [<ffffffff814573db>] acpi_ps_peek
> _opcode+0xd/0x1f
> [    2.109445] RSP: e02b:ffffffff81c03ce8  EFLAGS: 00010283
> [    2.109490] RAX: 000000000000000c RBX: ffff880014887000 RCX: ffffffff81c03d50
> [    2.109539] RDX: ffffc90000ee74e0 RSI: ffff880014887030 RDI: ffff880014887030
> [    2.109587] RBP: ffffffff81c03ce8 R08: ffffea0000522600 R09: ffffffff81432c4f
> [    2.109635] R10: ffff880014899090 R11: 00000000000000ba R12: ffff880014887030
> [    2.109684] R13: ffff880014887000 R14: ffffffff81c03d50 R15: 000000000000000d
> [    2.109735] FS:  0000000000000000(0000) GS:ffff880018c00000(0000) knlGS:00000
> 00000000000
> [    2.109836] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    2.109881] CR2: ffffc90000ee74e0 CR3: 0000000001c15000 CR4: 0000000000042660
> [    2.109930] Stack:
> [    2.109968]  ffffffff81c03d38 ffffffff81456537 ffffffff81c03d28 ffffffff81457
> a40
> [    2.110104]  ffff880014887000 ffff880014887000 ffff8800148990c0 ffffc90000ee7
> 4e0
> [    2.110238]  ffff880014887030 0000000000000000 ffffffff81c03d78 ffffffff81456
> 760
> [    2.110373] Call Trace:
> [    2.110413]  [<ffffffff81456537>] acpi_ps_get_next_arg+0x114/0x1f9
> [    2.110461]  [<ffffffff81457a40>] ? acpi_ps_pop_scope+0x54/0x72
> [    2.110508]  [<ffffffff81456760>] acpi_ps_get_arguments+0x91/0x228
> [    2.110555]  [<ffffffff81456ad2>] acpi_ps_parse_loop+0x1db/0x311
> [    2.110602]  [<ffffffff81457705>] acpi_ps_parse_aml+0x96/0x275
> [    2.110649]  [<ffffffff8145322f>] acpi_ns_one_complete_parse+0xf7/0x114
> [    2.110698]  [<ffffffff817d149a>] ? _raw_spin_lock_irqsave+0x1a/0x60
> [    2.110746]  [<ffffffff8145326c>] acpi_ns_parse_table+0x20/0x38
> [    2.110792]  [<ffffffff81452c20>] acpi_ns_load_table+0x4c/0x90
> [    2.110840]  [<ffffffff817c50b5>] acpi_tb_load_namespace+0xa6/0x14a
> [    2.110889]  [<ffffffff81d83269>] acpi_load_tables+0xc/0x35
> [    2.110935]  [<ffffffff81454bf6>] ? acpi_ns_get_node+0xb7/0xc9
> [    2.110982]  [<ffffffff81d825cf>] acpi_early_init+0x73/0x105
> [    2.111029]  [<ffffffff81d3b083>] start_kernel+0x348/0x3f0
> [    2.111075]  [<ffffffff81d3abcd>] ? set_init_arg+0x56/0x56
> [    2.111121]  [<ffffffff81d3a5f8>] x86_64_start_reservations+0x2a/0x2c
> [    2.111169]  [<ffffffff81d3e88c>] xen_start_kernel+0x4f5/0x4f7
> [    2.111215] Code: 8a 87 60 05 87 81 5d c3 e8 73 cc 37 00 55 81 ff 00 01 00 00
>  19 c0 48 89 e5 83 c0 02 5d c3 e8 5d cc 3
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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