.
>
> Signed-off-by: Matt Fleming
I luvz me some cleanups!
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majo
On Wed, Jan 29, 2014 at 04:23:47PM +, Matt Fleming wrote:
> From: Matt Fleming
>
> handover_offset is now filled out by build.c. Don't set a default value
> as it will be overwritten anyway.
>
> Signed-off-by: Matt Fleming
Acked-by: Borislav Petkov
> ---
>
On Thu, Jan 23, 2014 at 09:30:19AM -0700, Toshi Kani wrote:
> Since this issue is quite serious on our systems (3.14 kernels won't
> boot up), I'd really appreciate if the fixes can be made into some
> 3.14-rc. It can hit on any EFI systems with large memory.
That's why we have "efi=old_map" - so
On Mon, Jan 20, 2014 at 01:44:07PM +, Matt Fleming wrote:
> > +void __init kexec_enter_virtual_mode(void)
> > +{
>
> Could this be static for now?
Didn't you wanna do arch/x86/platform/efi/kexec.c anyway?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
On Mon, Jan 20, 2014 at 01:38:02PM +, Matt Fleming wrote:
> > +config EFI_PGT_DUMP
> > + bool "Dump the EFI pagetable"
> > + depends on EFI && X86_PTDUMP
> > + ---help---
> > + Enable this if you want to dump the EFI page table before
> > + enabling virtual mode. This can be used
From: Borislav Petkov
With reusing the ->trampoline_pgd page table for mapping EFI regions in
order to use them after having switched to EFI virtual mode, it is very
useful to be able to dump aforementioned page table in dmesg. This adds
that functionality through the walk_pgd_level() interf
From: Borislav Petkov
We will use it in efi so expose it.
Signed-off-by: Borislav Petkov
Tested-by: Toshi Kani
---
arch/x86/include/asm/pgtable_types.h | 2 ++
arch/x86/mm/pageattr.c | 44 +---
2 files changed, 33 insertions(+), 13 deletions
From: Borislav Petkov
Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc() manner of
From: Borislav Petkov
... into a kexec flavor for better code readability and simplicity. The
original one was getting ugly with ifdeffery.
Signed-off-by: Borislav Petkov
Tested-by: Toshi Kani
---
arch/x86/platform/efi/efi.c | 148 +---
include/linux
From: Borislav Petkov
This is very useful for debugging issues with the recently added
pagetable switching code for EFI virtual mode.
Signed-off-by: Borislav Petkov
Tested-by: Toshi Kani
---
arch/x86/Kconfig | 9 +
arch/x86/include/asm/efi.h | 1 +
arch/x86/platform
From: Borislav Petkov
Hi all,
this is the latest incarnation which should hopefully work just fine. It
tpasses esting at least on all our boxes so we have *some* coverage.
It took us a long time to debug the unmapping path and realize how
exactly we're doing the PGD sharing between the k
On Mon, Jan 13, 2014 at 06:48:10AM -0800, Arjan van de Ven wrote:
> >MODULE_LICENSE("GPL");
> >MODULE_AUTHOR("Arjan van de Ven ");
> >MODULE_DESCRIPTION("Kernel debugging helper that dumps pagetables");
>
> personally I consider it good form to always have this kind of
> information in .c files, re
On Mon, Jan 13, 2014 at 01:40:39PM +0800, Dave Young wrote:
> Adding a safeguard check for desc_size is better though currently it's
> impossible for the desc_size > PAGE_SIZE?
Huh, what?
sizeof(efi_memory_desc_t) is only 40 bytes AFAICT.
--
Regards/Gruss,
Boris.
Sent from a fat crate unde
On Mon, Jan 13, 2014 at 01:32:40PM +0800, Dave Young wrote:
> pr_info? This is for debug purpose, maybe pr_debug is better?
I hate pr_debug as it depends on other defines I have to have defined
properly in order just so I get output.
> How about do not limit to only if (pgd) case, instead do some
_SERVICES))
> efi_enter_virtual_mode();
> @@ -641,7 +642,6 @@ asmlinkage void __init start_kernel(void
>
> check_bugs();
>
> - acpi_early_init(); /* before LAPIC and SMP init */
> sfi_init_late();
>
> if (efi_enabled(EFI_RUNTIME_SER
From: Borislav Petkov
This is very useful for debugging issues with the recently added
pagetable switching code for EFI virtual mode.
Signed-off-by: Borislav Petkov
---
arch/x86/platform/efi/efi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b
From: Borislav Petkov
Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc() manner of
From: Borislav Petkov
With reusing the ->trampoline_pgd page table for mapping EFI regions in
order to use them after having switched to EFI virtual mode, it is very
useful to be able to dump aforementioned page table in dmesg. This adds
that functionality through the walk_pgd_level() interf
From: Borislav Petkov
Ok, here's v2 rebased and rediffed against tip (which has the relevant
efi branches).
Toshi, I'm pushing it to:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git#efi-fixes
so that you can give it another run and so that the build robot can poke
at i
From: Borislav Petkov
We will use it in efi so expose it.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/pgtable_types.h | 2 ++
arch/x86/mm/pageattr.c | 44 +---
2 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/arch/x86
On Thu, Dec 19, 2013 at 08:30:48PM -0800, H. Peter Anvin wrote:
> On 12/19/2013 08:24 PM, joeyli wrote:
> > I agreed, but userspace application should not be too often to access
> > RTC. Maybe only when system boot and set timezone.
>
> This is, quite frankly, an idiotic argument.
TBH, I've been s
On Wed, Dec 18, 2013 at 05:07:57PM +0800, Dave Young wrote:
> How about firstly count the md numbers in the 1st loop, then
> get/roundup the total size, alloc the pages, map the mds one by one in
> another loop.
No need as most systems would never need to reallocate. Even on Toshi's
big system, th
On Tue, Dec 17, 2013 at 02:34:36PM +0800, Dave Young wrote:
> They are moved to efi.c efi_setup_init(), I'm not sure if I expained
> clear enough, in current code parse_efi_setup only accept one argument
> phys_addr so I will mapping it with sizeof(struct setup_data) to
> get the payload size then
On Tue, Dec 17, 2013 at 01:51:56PM +, Matt Fleming wrote:
> Couldn't we do the mapping in efi_setup_page_tables() if we pass
> __pa(new_memmap) and 1 << new_memmap_shift as arguments?
Yep, not a bad idea. I'll give it a try.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under
On Tue, Dec 17, 2013 at 12:10:24PM +, Matt Fleming wrote:
> You sunk my i386 battleship,
>
> /home/build/git/efi/arch/x86/platform/efi/efi.c:824:24: error: ‘struct
> real_mode_header’ has no member named ‘trampoline_pgd’
> make[4]: *** [arch/x86/platform/efi/efi.o] Error 1
> make[3]: *** [arc
On Tue, Dec 17, 2013 at 12:36:37AM +0100, Borislav Petkov wrote:
> @@ -880,6 +906,19 @@ void __init efi_enter_virtual_mode(void)
>
> efi_dump_pagetable();
>
> + /*
> + * It can happen that the physical address of new_memmap lands in memory
> + * which
From: Borislav Petkov
With reusing the ->trampoline_pgd page table for mapping EFI regions in
order to use them after having switched to EFI virtual mode, it is very
useful to be able to dump aforementioned page table in dmesg. This adds
that functionality through the walk_pgd_level() interf
From: Borislav Petkov
Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc() manner of
From: Borislav Petkov
This is very useful for debugging issues with the recently added
pagetable switching code for EFI virtual mode.
Signed-off-by: Borislav Petkov
---
arch/x86/platform/efi/efi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b
From: Borislav Petkov
Hi guys,
this is the result of Toshi and me debugging a #GP on one of his big HP
boxes sporting UEFI. Each commit message should be self-explanatory so
please look there.
This has more or less an RFC nature thus I'm sending it now to collect
feedback. It is going to
On Mon, Dec 16, 2013 at 10:00:10AM +0800, Dave Young wrote:
> > > - print_efi_memmap();
> > > + if (efi_setup) {
> > > + int s;
> > > + struct efi_setup_data *data;
> > > +
> > > + s = sizeof(*data) + nr_efi_runtime_map * sizeof(data->map[0]);
> > > + data = early_me
early params so they can be set as reserved ranges and later
> ioremap will be fine with it.
>
> changes:
> Boris: improve patch description
>
> Signed-off-by: Dave Young
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting
/* setup_data type of setup_data node 0, hex string */
> [snip]
> |__ version /* boot protocal version (in hex, "0x" prefixed)*/
>
> Changelog:
> Greg: use __ATTR_RO() and group attr.
> Matt and Boris: Documentation improvement, code indentation.
>
&
On Mon, Dec 09, 2013 at 05:42:23PM +0800, Dave Young wrote:
> For kexec/kdump kernel efi runtime mappings are saved, printing original whole
> memmap ranges does not make sense anymore. So introduce a new function to only
> print runtime maps in case kexec/kdump kernel is used.
>
> changelog:
> Ma
On Thu, Dec 12, 2013 at 03:17:43PM +0800, Dave Young wrote:
> Rethink about this issue, moving them to efi_$(BITS).c I need move the
> efi_setup from a static variable to an extern, It looks not worth.
Dave, would you please do what is suggested to you? A big part of
the efi code is split into 32-
On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
> Sorry that I forgot to explain this in changelog, should ask you before.
>
> I did try moving it to efisubsys_init but it need add extern declaration
So what? Add it.
> for efi_runtime_map_init. Since link order will ensure it being c
On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote:
> BTW, I will restructure the whole code when I move them to
> efi_kexec.c, so no worry about it? If you have strong opinion I can
> move them though.
Well, if it were me, I'd do it now so that it'll see more testing.
Later, it will be on
On Thu, Dec 12, 2013 at 10:36:17AM -0700, Toshi Kani wrote:
> BTW, the test system is shared and will be used by other test for a
> couple of hours or so. So, please take your time. :-)
Yeah, ok :-)
I went and polished the debugging patch a bit more - it seems we're
going to need it more often no
On Wed, Dec 11, 2013 at 06:10:20PM -0700, Toshi Kani wrote:
> > Unfortunately, it did not work. Hit the same panic again.
>
> dmesg output attached.
Ok, thanks.
Let's have a look at the EFI pagetable then. Please apply the attached
patch, make sure CONFIG_X86_PTDUMP is enabled, build, boot and
On Wed, Dec 11, 2013 at 05:01:03PM -0700, Toshi Kani wrote:
> Hi Boris,
>
> An EFI tree kernel panic'd during boot on one of my systems. It boots
> fine when efi=old_map option is specified. So, I think it is caused by
> your EFI virtual mapping changes.
>
> The panic message is as follows. I
On Mon, Dec 09, 2013 at 05:42:22PM +0800, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi runtime ragions which
> we passed in previously.
On Mon, Dec 09, 2013 at 05:42:21PM +0800, Dave Young wrote:
> kexec kernel will need exactly same mapping for
> efi runtime memory ranges. Thus here export the
> runtime ranges mapping to sysfs, kexec-tools
> will assemble them and pass to 2nd kernel via
> setup_data.
>
> Introducing a new directo
On Mon, Dec 09, 2013 at 05:42:20PM +0800, Dave Young wrote:
> Export fw_vendor, runtime and config table physical addresses to
> /sys/firmware/efi/fw_vendor, /sys/firmware/efi/runtime and
> /sys/firmware/efi/config_table because kexec kernel will need them.
you might wanna shorten:
... sys/firmwa
On Mon, Dec 09, 2013 at 05:42:15PM +0800, Dave Young wrote:
> In arch/x86/platform/efi/efi.c and drivers/firmware/efi/efi.c turn to use
> early_memremap/early_memunmap instead of early_ioremap/early_iounmap so sparse
> will be happy.
>
> Signed-off-by: Dave Young
Acked-by:
On Wed, Dec 11, 2013 at 12:13:52PM +, Matt Fleming wrote:
> > + for (i = 0, md = data->map; i < nr_efi_runtime_map; i++, md++) {
> > + efi_map_region_fixed(md); /* FIXME: add error handling */
>
> Oops. Please fix this ;-)
Yeah, this is on my TODO as it wraps around __map_region,
On Wed, Dec 11, 2013 at 10:20:25AM +, Matt Fleming wrote:
> This needs reviewing by at least one of the x86 folks, but it
> certainly makes sense to me.
Ingo told me yesterday, it makes sense too. I'd guess we can try it.
FWIW, all callers of early_memremap use the memory they get remapped as
On Tue, Dec 10, 2013 at 03:25:49PM -0800, Andrew Morton wrote:
> On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young wrote:
>
> > Here is the V5 patchset for supporting kexec kernel efi runtime.
>
> It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
> patch which actually hits on e
On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
> There's a lot of sparse warnings for code like below:
> void *a = early_memremap(phys_addr, size);
>
> early_memremap intend to map kernel memory with ioremap facility, the return
> pointer should be a kernel ram pointer instead of iome
On Sat, Dec 07, 2013 at 04:01:02AM -0500, Dave Young wrote:
> Hi, all
>
> Update my status:
>
> I have finished most of thecode related changes including the krealloc
> fixes (both for original code and my new code). And I'm slowly
> moving the kexec related stuff to efi_kexec.c, this involves
>
On Thu, Dec 05, 2013 at 08:56:02AM -0700, Toshi Kani wrote:
> The smbios in efi_setup_data is necessary for kexec to pass the physical
> address of the SMBIOS table from the 1st kernel to the 2nd kernel.
>
> The kernel boot sequence proceeds in the following order. Step 2
> requires efi.smbios to
On Thu, Dec 05, 2013 at 09:56:15AM +0800, Dave Young wrote:
> > The z420 firmware is based on some UEFI core that may be used by other
> > vendors as well. Since this handling is totally harmless (just
> > redundant), I'd suggest not to have a platform check on this handling.
>
> I have same worr
On Mon, Dec 02, 2013 at 10:49:15AM +0800, Dave Young wrote:
> All these setup_data passing, remapping etc. is mostly for kexec,
> add a lot of contiditional #if #endif makes the code a mess. I would
> prefer to not do this if you are not strongly object.
Right, having efi_kexec.c could solve all t
On Mon, Dec 02, 2013 at 10:59:42AM +0800, Dave Young wrote:
> They are only called if there's setup_data SETUP_EFI passed in. Yes, I
> think only kexec need that part of code. But I hesitated to mess the
> code with a lot of #if. Will think about it.
Well, the accepted strategy with the efi code i
On Sat, Nov 30, 2013 at 06:04:07AM +0800, joeyli wrote:
> I am sure his patchset can walkaround physical address accessing issue
> on a broken 64-bit machine. But, I didn't test it on 32-bit issue
> machine.
Yeah, my patches don't change 32-bit so I wouldn't expect any
difference, unfortunately.
On Fri, Nov 29, 2013 at 04:28:22PM +0800, Dave Young wrote:
> I think for anyone who are using early_memremap should know this is a
> normal kernel memory instead of real __iomem
You can never ever assume that people are using kernel interfaces
correctly.
--
Regards/Gruss,
Boris.
Sent from
On Fri, Nov 29, 2013 at 04:35:52PM +0800, Dave Young wrote:
> Is below changes ok to you?
Almost perfect! Just a micro-nitpick below:
> Currently e820_reserve_setup_data is called before parsing early params,
> it works in normal case. But for memmap=exactmap, the final memory ranges
> are create
On Fri, Nov 29, 2013 at 04:50:50PM +0800, Dave Young wrote:
> It's for debugging purpose, I think it's helpful.
Why? The first kernel did dump it already.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "un
On Fri, Nov 29, 2013 at 05:14:16PM +0800, Dave Young wrote:
> That's reserved for future extension use, who knows if we will need to
> pass other fields in the future.
Hrrmmm, 8*64 = 64 Bytes?? And you can't change it later because of the
situation where machines might be using older kexec-tools?
On Fri, Nov 29, 2013 at 05:40:35PM +0800, Dave Young wrote:
> Matt are suggesting to below one, is it ok to you? I'm fine with both.
>
> The efi runtime services can only be switched to virtual mode once
> without rebooting. The kexec kernel must maintain the same physical
> to virtual address mapp
On Tue, Nov 26, 2013 at 01:57:56PM +0800, Dave Young wrote:
> Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
> parsing early params so they can be set reserved finally. Or kdump kernel
> will warn about ioremap a normal ram range.
I had to stare for a while at this commit m
On Tue, Nov 26, 2013 at 01:57:55PM +0800, Dave Young wrote:
> kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
> the kexec kernel efi runtime support also need read the old efi_info from
> boot_params. Currently it exists in debugfs which is not a good place for
> such infom
On Wed, Nov 27, 2013 at 10:27:01AM +, Matt Fleming wrote:
> Heh, you can probably already guess what I'm going to say here...
I guessed :-)
> How about using a single function to dump the memory ranges irrespective
> of whether the memory map comes from 'memmap' or 'esdata'? e.g.
> something
so kexec-tools
> will check the flag and switch to old logic.
>
> changelog:
> Matt: +&& defined(CONFIG_KEXEC)
> HPA: document the flag.
>
> Signed-off-by: Dave Young
Other than that:
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from a fat crate under
On Tue, Nov 26, 2013 at 01:57:52PM +0800, Dave Young wrote:
> Add a new setup_data type SETUP_EFI for kexec use.
> Passing the saved fw_vendor, runtime, config tables and
> efi runtime mappings.
>
> When entering virtual mode, directly mapping the efi
> runtime ragions which we passed in previousl
On Wed, Nov 27, 2013 at 05:29:46PM +0800, Dave Young wrote:
> I would like to send a new version which addressing several issues for
> code structure improvement and changelog etc.
>
> If there's no further comments I will send them tommorrow.
As a rule of thumb you should wait ~week and give chan
On Tue, Nov 26, 2013 at 01:57:51PM +0800, Dave Young wrote:
> kexec kernel will need exactly same mapping for
> efi runtime memory ranges. Thus here export the
> runtime ranges mapping to sysfs, kexec-tools
> will assemble them and pass to 2nd kernel via
> setup_data.
>
> Introducing a new directl
On Tue, Nov 26, 2013 at 12:26:50PM +0100, Ingo Molnar wrote:
> Just a side note, for future reference, this title lacks a verb and is
> thus not self-describing:
>
>x86/efi: Runtime services virtual mapping
>
> It should probably have been something like:
>
>x86/efi: Implement and enabl
On Tue, Nov 26, 2013 at 01:57:50PM +0800, Dave Young wrote:
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 2e2fbde..5d85956 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -32,6 +32,9 @@ struct efi __read_mostly efi = {
> .hcdp
On Mon, Nov 25, 2013 at 05:19:57PM +0800, Dave Young wrote:
> Sigh, looks like I should move to git-send-email for less error prone.
You won't regret it :-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "
On Fri, Nov 22, 2013 at 10:48:50AM +0800, Dave Young wrote:
> > efi.config_table = (unsigned long)efi.systab->tables;
> > efi.fw_vendor= (unsigned long)efi.systab->fw_vendor;
> > efi.runtime = (unsigned long)efi.systab->runtime;
>
> Hmm, UEFI spec mentions the them like below
On Thu, Nov 21, 2013 at 02:01:26PM -0700, Jerry Hoemann wrote:
> Some platform have firmware that violate the UEFI spec and access boot service
> code or data segments after the system has called ExitBootServices().
> The call to efi_reserve_boot_services is a workaround to avoid using
> boot servi
On Thu, Nov 21, 2013 at 02:17:05PM +0800, dyo...@redhat.com wrote:
> variables size and end is useless in this function, thus remove them.
>
> Reported-by: Toshi Kani
> Signed-off-by: Dave Young
Good catch.
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from a fat
> Toshi Kani:
> remove unused variable
> Matt: check return value of krealloc.
>
> Signed-off-by: Dave Young
Same short comment nitpick as earlier :)
Otherwise:
Acked-by: Borislav Petkov
> ---
> arch/x86/platform/efi/efi.c | 109
> ++
aved in md->virt_addr.
>
> Matt: coding style
> reuse __map_region
>
> Signed-off-by: Dave Young
Except minor nitpick below:
Acked-by: Borislav Petkov
> ---
> arch/x86/include/asm/efi.h |1 +
> arch/x86/platform/efi/efi_32.c |2 ++
> arch/x86
On Thu, Nov 21, 2013 at 02:17:09PM +0800, dyo...@redhat.com wrote:
> --- efi.orig/arch/x86/platform/efi/efi.c
> +++ efi/arch/x86/platform/efi/efi.c
> @@ -653,6 +653,10 @@ void __init efi_init(void)
>
> set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility);
>
> + efi.fw_vendor = (unsigned long
On Tue, Nov 05, 2013 at 04:20:07PM +0800, dyo...@redhat.com wrote:
> Please help to review the patches.
Sure, but will have to wait 'til next week when I get back.
Thanks.
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message t
On Fri, Nov 01, 2013 at 09:18:25AM +0800, Dave Young wrote:
> Great, thank you. BTW, I have managed to test original patch set on a
> Macboot Air of my friend with usb boot, it works ok.
Ok, that's actually a very good news - the apples tend to be special wrt
uefi implementation.
--
Regards/Grus
From: Borislav Petkov
Add the ability to map pages in an arbitrary pgd. This wires in the
remaining stuff so that there's a new interface with which you can map a
region into an arbitrary PGD.
Signed-off-by: Borislav Petkov
---
arch/x86/mm/pageattr.c
From: Borislav Petkov
Handle last level by unconditionally writing the PTEs into the PTE page
while paying attention to the NX bit.
Signed-off-by: Borislav Petkov
---
arch/x86/mm/pageattr.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm
From: Borislav Petkov
Add the next level of the pagetable populating function, we handle
chunks around a 1G boundary by mapping them with the lower level
functions - otherwise we use 1G pages for the mappings, thus using as
less amount of pagetable pages as possible.
Signed-off-by: Borislav
From: Borislav Petkov
Check it just in case. We might just as well panic there because runtime
won't be functioning anyway.
Signed-off-by: Borislav Petkov
---
arch/x86/platform/efi/efi.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arc
From: Borislav Petkov
We try to free the pagetable pages once we've unmapped our portion.
Signed-off-by: Borislav Petkov
---
arch/x86/mm/pageattr.c | 94 +-
1 file changed, 93 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/pageatt
From: Borislav Petkov
Hi all,
here's maybe the final version of the patchset, no major changes since
the last time but cosmetic and cleanups and tidying as requested by Matt
and others.
Patches also at:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git#efi
The previous announc
From: Borislav Petkov
This is preparatory work in order to be able to map pages into a
specified PGD and not implicitly and only into init_mm.
Signed-off-by: Borislav Petkov
---
arch/x86/mm/pageattr.c | 36 ++--
1 file changed, 26 insertions(+), 10 deletions
From: Borislav Petkov
In case we encounter an error during the mapping of a region, we want to
unwind what we've established so far exactly the way we did the mapping.
This is the PUD part kept deliberately small for easier review.
Signed-off-by: Borislav Petkov
---
arch/x86/mm/pagea
From: Borislav Petkov
Handle PMD-level mappings the same as PUD ones.
Signed-off-by: Borislav Petkov
---
arch/x86/mm/pageattr.c | 82 +-
1 file changed, 81 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm
From: Borislav Petkov
We map the EFI regions needed for runtime services non-contiguously,
with preserved alignment on virtual addresses starting from -4G down
for a total max space of 64G. This way, we provide for stable runtime
services addresses across kernels so that a kexec'd kerne
From: Borislav Petkov
... and lose one #ifdef .. #endif sandwich.
Signed-off-by: Borislav Petkov
---
arch/x86/platform/efi/efi.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 1d3372ac9c66
From: Borislav Petkov
This allocates, if necessary, and populates the corresponding PGD entry
with a PUD page. The next population level is a dummy macro which will
be removed by the next patch and it is added here to keep the patch
small and easily reviewable but not break bisection, at the
On Wed, Oct 30, 2013 at 08:07:45PM -0700, H. Peter Anvin wrote:
> You can use git for your own purposes, still.
git mk-coffee --refill --now
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linu
Dear Mr. Young,
On Thu, Oct 31, 2013 at 10:07:14AM +0800, Dave Young wrote:
> > But Frankly I'd like to see them in list instead even with only small fixes
> > beacuse in this way there might be more people to review it carefully.
>
> There's another shorcoming for keeping new patches in git is t
On Wed, Oct 30, 2013 at 10:03:49AM +0800, Dave Young wrote:
> Will try, but please keep the posted patches in mailing list up-to-date,
Would you like me to send them to you privately?
> I'm an old-fashioned person, do not tend to depend on git.
Really? You should change that - you're missing out
On Wed, Oct 30, 2013 at 05:32:27PM +0800, Dave Young wrote:
> Boris, thanks for update, it's very elaborate, I have still wonder if
> 32 bit case should be mentioned as well.
Ah, so that's why is mfleming bugging me about it on IRC :)
Well, I left out the 32-bit case simply because I don't think
On Tue, Oct 29, 2013 at 10:32:03AM +0800, Dave Young wrote:
> I remember I tried your efi branch, but the code is different from
> what you sent to list, thus I turned to use the mbox patches.
Yeah, please use the #efi branch as I keep refreshing it with the newest
changes. They're hopefully not s
On Tue, Oct 29, 2013 at 02:47:20PM +0800, Dave Young wrote:
> Boris, could you update the comment? it says below: update that memory
> descriptor with the virtual address obtained from ioremap().
>
> Logiclly your patch should update it, then my patch update it again
> with the case of mapping to f
On Mon, Oct 28, 2013 at 11:22:46AM +, Matt Fleming wrote:
> Could you use the efi_enabled() function to test for EFI_OLD_MEMMAP
> instead of test_bit()?
Sure.
> This way we won't exhaust the bitspace quite so soon (since ARM/ARM64
Yeah, very foresightful.
> can reuse EFI_ARCH_1 if they need
On Mon, Oct 28, 2013 at 07:24:58PM +0800, Dave Young wrote:
> I use linus tree, git pull Matt's efi-next tree, then apply your 12
> patches and my patches. I applied your previous 11 patches + the last
> update patch 12/12, but the last one does not apply, I manually shift
> a hunk to make it apply
On Mon, Oct 28, 2013 at 06:10:11PM +0800, Dave Young wrote:
> Sorry, I have not any public git account. Attached the patch I applied
> with git
Still doesn't work:
$ patch -p1 --dry-run -i /tmp/02-efi-enter-virtual-mode-cleanup-1.patch.new
checking file arch/x86/platform/efi/efi.c
Hunk #1 succee
On Mon, Oct 28, 2013 at 11:02:13AM +, Matt Fleming wrote:
> This patch should be part of PATCH 12.
I wanted it to be separate as it adds an unrelated functionality but I
don't really care all that much - I'll merge it.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Format
On Mon, Oct 28, 2013 at 05:51:17PM +0800, Dave Young wrote:
> It does have a warning, but it applied successfully, no idea though:
> patches/02-efi-enter-virtual-mode-cleanup.patch
> Applying: Cleanup efi_enter_virtual_mode function
> /home/dave/git/efi/.git/rebase-apply/patch:42: space before tab
401 - 500 of 619 matches
Mail list logo
