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, l
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 talke
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 wrote:
>On Wed, Oct 02, 2013 at 11:46:44AM -0700, H. Peter Anvin wrote:
>> It's pre
On Wed, Oct 02, 2013 at 11:46:44AM -0700, H. Peter Anvin wrote:
> It's pretty straightforward - just drop the starting address to proper
> alignment after you subtract the size.
Ok, just an observation - it is not necessarily a bad thing but I
thought we should talk about it:
So, when we do the V
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 Wed, Oct 02, 2013 at 10:32:19AM -0700, H. Peter Anvin wrote:
> So this is a bug in the sense that 2M pages were used when they were
> not safe to use (matching alignment is part of the requirement for 2M
> pages being allowable.) However, we of course want to use 2M pages, so
> see below.
Yes,
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 ca
On Wed, Oct 02, 2013 at 08:43:52AM -0700, H. Peter Anvin wrote:
> On 10/02/2013 03:04 AM, Borislav Petkov wrote:
> > When we start allocating from -4G, i.e. 0x, I think we
> > want to do it bottom-up so that 0x is the *last*, i.e.
> > lowest address. Because we link
On 10/02/2013 03:04 AM, Borislav Petkov wrote:
> When we start allocating from -4G, i.e. 0x, I think we
> want to do it bottom-up so that 0x is the *last*, i.e.
> lowest address. Because we link the kernel text at 0x8100 by
> default, which would mean, if
On Mon, Sep 23, 2013 at 08:06:38PM -0700, 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.
>
Ok, so I'm looking at this agan and, actually, we really do subtract the
region size *before* we as
On Mon, Sep 30, 2013 at 11:06:46PM +0200, Borislav Petkov wrote:
> On Mon, Sep 30, 2013 at 04:46:42PM -0400, Vivek Goyal wrote:
> > On Mon, Sep 30, 2013 at 10:41:54PM +0200, Borislav Petkov wrote:
> >
> > [..]
> > > hpa, so, for the struct efi_mapping thing to work, I will have to grep
> > > dmesg
On Mon, Sep 30, 2013 at 04:46:42PM -0400, Vivek Goyal wrote:
> On Mon, Sep 30, 2013 at 10:41:54PM +0200, Borislav Petkov wrote:
>
> [..]
> > hpa, so, for the struct efi_mapping thing to work, I will have to grep
> > dmesg of the first kernel to get an output like the one below, filter
> > the runt
On Mon, Sep 30, 2013 at 04:35:05PM -0400, Vivek Goyal wrote:
> 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 wil
On Mon, Sep 30, 2013 at 10:41:54PM +0200, Borislav Petkov wrote:
[..]
> hpa, so, for the struct efi_mapping thing to work, I will have to grep
> dmesg of the first kernel to get an output like the one below, filter
> the runtime regions so that I can build the struct efi_mapping array of
> mem reg
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? Dur
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 09/24/13 at 05:12pm, H. Peter Anvin wrote:
> 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
> >
On Sat, September 21, 2013 1:39 pm, Borislav Petkov wrote:
> diff --git a/arch/x86/platform/efi/efi_32.c
> b/arch/x86/platform/efi/efi_32.c
> index 40e446941dd7..661663b08eaf 100644
> --- a/arch/x86/platform/efi/efi_32.c
> +++ b/arch/x86/platform/efi/efi_32.c
> @@ -37,9 +37,36 @@
> * claim EFI ru
On Tue, Sep 24, 2013 at 05:12:26PM -0700, H. Peter Anvin wrote:
> I am starting to think that we really should explicitly pass along the
> EFI mappings to the secondary kernel. This will also help if we have to
> change the algorithm in a future kernel.
That would be the most flexible solution, s
On 09/24/13 at 05:12pm, H. Peter Anvin wrote:
> 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
> >
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,
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
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 layout the regions is arbitrary as long as we start
On 09/24/13 at 11:43am, Borislav Petkov wrote:
> Crap,
>
> I need to send from the web interface since the network here doesn't
> somehow let through port 587.
>
> On Tue, September 24, 2013 6:57 am, Dave Young wrote:
> > On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
> >> Okay... I see two proble
On 09/24/13 at 11:43am, Borislav Petkov wrote:
> Crap,
>
> I need to send from the web interface since the network here doesn't
> somehow let through port 587.
>
> On Tue, September 24, 2013 6:57 am, Dave Young wrote:
> > On 09/23/13 at 08:06pm, H. Peter Anvin wrote:
> >> Okay... I see two proble
Crap,
I need to send from the web interface since the network here doesn't
somehow let through port 587.
On Tue, September 24, 2013 6:57 am, 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, r
On 09/24/13 at 01:23pm, Dave Young wrote:
> 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 tha
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 expl
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.
> >
> > 2. The second region is assigned the same address in the sec
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 t
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 first region was somehow set to zero.
Dave Young wrote:
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 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 * (1U
On 09/23/13 at 08:29am, Borislav Petkov wrote:
> 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"
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;
> > + }
> > +
> > +
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
> >
> > We map the EFI regions needed for runtime services contiguously on
> > virtual addresses starting from -4G down for a total max space of 64G.
> > Thi
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 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
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 buil
On 09/22/13 at 10:00pm, Dave Young wrote:
> 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 i
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
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/21/13 at 01:39pm, Borislav Petkov wrote:
> On Thu, Sep 19, 2013 at 04:54:54PM +0200, Borislav Petkov wrote:
> > From: Borislav Petkov
> >
> > We map the EFI regions needed for runtime services contiguously on
> > virtual addresses starting from -4G down for a total max space of 64G.
> > Thi
On Thu, Sep 19, 2013 at 04:54:54PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov
>
> 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 addresses acr
44 matches
Mail list logo
