[PATCH 2/??] memory allocation fix

From: Doug Goldstein <cardoe@cardoe.com>
To: xen-devel@lists.xenproject.org
Cc: jgross@suse.com, sstabellini@kernel.org,
	andrew.cooper3@citrix.com, Doug Goldstein <cardoe@cardoe.com>,
	pgnet.dev@gmail.com, ning.sun@intel.com, julien.grall@arm.com,
	jbeulich@suse.com, qiaowei.ren@intel.com, gang.wei@intel.com,
	fu.wei@linaro.org
Subject: [PATCH 2/??] memory allocation fix
Date: Tue, 10 Jan 2017 17:12:10 -0600	[thread overview]
Message-ID: <20170110231210.16576-1-cardoe@cardoe.com> (raw)
In-Reply-To: <1480976718-12198-1-git-send-email-daniel.kiper@oracle.com>

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

---
Daniel,

Feel free to fold this in where it needs to go or break this up into
a patch (or patches) part of your series. This is what it took for me to
get it to boot on one of my Intel NUCs and to get into the dom0 kernel
booting on my other machines. There's still an issue with the page tables
somewhere I believe because that's where its dying on the other machines.
Writing to cr3 or cr0. QEMU is likely an issue with OVMF or what they're doing.
0x7fb27408 is smack in the middle of ACPI NVS.

(XEN) [    5.506811]    [<000000007fb27408>] 000000007fb27408
(XEN) [    5.509252]    [<ffff82d080235c7b>] vsnprintf+0x7eb/0xb70
(XEN) [    5.511779]    [<ffff82d080277fda>] i387.c#_vcpu_save_fpu+0x8a/0x180
(XEN) [    5.514548]    [<ffff82d080202374>] efi_runtime_call+0xa24/0xac0
(XEN) [    5.517233]    [<ffff82d08020220e>] efi_runtime_call+0x8be/0xac0
(XEN) [    5.519853]    [<ffff82d08025dc41>] avc_has_perm+0x51/0x70
(XEN) [    5.521985]    [<ffff82d080298a1f>] do_platform_op+0x73f/0x16e0
(XEN) [    5.524604]    [<ffff82d080298a1f>] do_platform_op+0x73f/0x16e0
(XEN) [    5.527172]    [<ffff82d08028cb21>] do_mmu_update+0x221/0x12b0
(XEN) [    5.531455]    [<ffff82d0802982e0>] do_platform_op+0/0x16e0
(XEN) [    5.533421]    [<ffff82d080277dc6>] pv_hypercall+0xf6/0x1c0
(XEN) [    5.537808]    [<ffff82d080230c00>] timer.c#timer_softirq_action+0xc0/0x250
(XEN) [    5.543847]    [<ffff82d080230c72>] timer.c#timer_softirq_action+0x132/0x250
(XEN) [    5.546743]    [<ffff82d080326c6e>] entry.o#test_all_events+0/0x2a

This happens right after dom0 spits out:
[    0.368037] PTP clock support registered

As an aside given all the Intel guys CC'd, what's a communication channel I
can use to report issues with the NUC's EFI implementation that's not canned
responses from level 1 tech support?
---
 xen/arch/x86/efi/efi-boot.h | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index dc857d8..878f683 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -172,7 +172,7 @@ static void __init efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
             if ( !trampoline_phys && desc->PhysicalStart + len <= 0x100000 &&
                  len >= cfg.size + extra_mem &&
                  desc->PhysicalStart + len > cfg.addr )
-                cfg.addr = (desc->PhysicalStart + len - cfg.size) & PAGE_MASK;
+                cfg.addr = (desc->PhysicalStart + len - (cfg.size + extra_mem)) & PAGE_MASK;
             /* fall through */
         case EfiLoaderCode:
         case EfiLoaderData:
@@ -686,6 +686,14 @@ paddr_t __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTa
     setup_efi_pci();
     efi_variables();
 
+    cfg.addr = 0x100000;
+    cfg.size = (trampoline_end - trampoline_start) + (64 << 10);
+    if ( efi_bs->AllocatePages(AllocateMaxAddress, EfiLoaderData,
+                PFN_UP(cfg.size), &cfg.addr) != EFI_SUCCESS ) {
+        cfg.addr = 0;
+        PrintStr(L"Trampoline space cannot be allocated; will try fallback.\r\n");
+    }
+
     if ( gop )
         efi_set_gop_mode(gop, gop_mode);
 
-- 
2.10.2


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