Sorry for reply late because I was in a long holiday...
On 09/30/13 at 10:17pm, Borislav Petkov wrote:
On Thu, Sep 26, 2013 at 11:12:42AM +0800, Dave Young wrote:
If we choose this approach, can we save not only the efi_mapping, but
also the fields which will be converted to virt addr, like
We can do that... but it is different from what Windows does to my
understanding and it also has the potential of severe pathologies... e.g. a
window at the top of the address space being mapped.
Borislav Petkov b...@alien8.de wrote:
On Wed, Oct 02, 2013 at 11:46:44AM -0700, H. Peter Anvin
On Fri, Oct 04, 2013 at 07:43:37AM -0700, H. Peter Anvin wrote:
We can do that... but it is different from what Windows does to my
understanding and it also has the potential of severe pathologies...
e.g. a window at the top of the address space being mapped.
Right, so after Matt and I talked
On 10/02/2013 10:05 AM, Borislav Petkov wrote:
Btw, Matt just found another issue with the bottom-up approach - due to
different alignment of VA and PA addresses, this messes up the pagetable
in terms of the order in which we're using 4K, 2M, etc pages.
What can happen is that, you can get
On 10/02/2013 11:42 AM, Borislav Petkov wrote:
Yes, so the alignment has to be such that both PA and VA are the same
amount of 4K pages away from the next 2M boundary, to put it bluntly.
I have a couple of ideas on how to do that.
It's pretty straightforward - just drop the starting
On Thu, Sep 26, 2013 at 11:12:42AM +0800, Dave Young wrote:
If we choose this approach, can we save not only the efi_mapping, but
also the fields which will be converted to virt addr, like fw_vendor,
runtime, tables? During my test on a HP workstation, the config table
item (SMBIOS) also is
On Mon, Sep 30, 2013 at 10:17:30PM +0200, Borislav Petkov wrote:
On Thu, Sep 26, 2013 at 11:12:42AM +0800, Dave Young wrote:
If we choose this approach, can we save not only the efi_mapping, but
also the fields which will be converted to virt addr, like fw_vendor,
runtime, tables? During my
On 09/24/2013 07:56 AM, Borislav Petkov wrote:
On Tue, September 24, 2013 2:45 pm, Dave Young wrote:
Think again about this, how about 1:1 map them from a base address
like -64G phy_addr - (-64G + phy_addr), in this way we can avoid
depending on the previous region size.
Right, how we
On 09/24/13 at 04:56pm, Borislav Petkov wrote:
On Tue, September 24, 2013 2:45 pm, Dave Young wrote:
Think again about this, how about 1:1 map them from a base address
like -64G phy_addr - (-64G + phy_addr), in this way we can avoid
depending on the previous region size.
Right, how we
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
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
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 Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote:
I tested your new patch, it works both with efi stub and grub boot in
1st kernel.
Good, thanks!
But it paniced in kexec boot with my kexec related patcheset, the patchset
That's the second kernel, right?
contains 3 patch:
1.
On 09/22/13 at 03:37pm, Borislav Petkov wrote:
On Sun, Sep 22, 2013 at 08:35:15PM +0800, Dave Young wrote:
I tested your new patch, it works both with efi stub and grub boot in
1st kernel.
Good, thanks!
But it paniced in kexec boot with my kexec related patcheset, the patchset
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.
Assuming it isn't as simple as the mappings never get
On Sun, Sep 22, 2013 at 08:27:34AM -0700, H. Peter Anvin wrote:a
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
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.
This way, we provide for stable runtime services
21 matches
Mail list logo
