On 09/21/13 at 01:39pm, Borislav Petkov wrote:
On Thu, Sep 19, 2013 at 04:54:54PM +0200, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
We map the EFI regions needed for runtime services contiguously on
virtual addresses starting from -4G down for a total max space of 64G.
On Mon, Sep 23, 2013 at 01:47:41PM +0800, Dave Young wrote:
+ unsigned long size = md-num_pages PAGE_SHIFT;
+
+ efi_va -= size;
+ if (efi_va EFI_VA_END) {
+ pr_warning(FW_WARN VA address range overflow!\n);
+ return;
+ }
+
+ /* Do the 1:1 map */
On Sat, Sep 21, 2013 at 01:39:29PM +0200, Borislav Petkov wrote:
-void __init efi_call_phys_prelog(void)
+/*
+ * We allocate runtime services regions top-down, starting from -4G, i.e.
+ * 0x___ and limit EFI VA mapping space to 64G.
+ */
+static u64 efi_va = -4 * (1UL
The problem in efi_main was that the idt was cleared before the
interrupts were disabled.
The UEFI spec states that interrupts aren't used so this shouldn't be
too much of a problem. Peripherals however don't necessarily know about
this and thus might cause interrupts to happen anyway. Even if
On 09/22/13 at 08:27am, H. Peter Anvin wrote:
The address that faults is interesting in that it is indeed just below -4G.
The question at hand is probably what information you are using to build the
EFI mappings in the secondary kernel and what could make it not match the
primary.
On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
Okay... I see two problems.
1. It looks like we subtract the region size after, rather than before,
assigning an address.
2. The second region is assigned the same address in the secondary kernel as
in the first, implying the size of the
On 09/24/13 at 12:58pm, Dave Young wrote:
On 09/24/13 at 12:57pm, Dave Young wrote:
On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
Okay... I see two problems.
1. It looks like we subtract the region size after, rather than before,
assigning an address.
Could you explain more about
