On Fri, Feb 08, 2013 at 02:30:52PM -0800, H. Peter Anvin wrote:
Also, keep in mind that there is a very simple way to deny MSR access
completely, which is to not include the driver in your kernel (and not
allow module loading, but if you can load modules you can just load a
module to muck with
On Fri, Mar 01, 2013 at 02:32:47PM -0800, H. Peter Anvin wrote:
On 03/01/2013 01:39 PM, Borislav Petkov wrote:
Hi guys,
so I was talking with mfleming on IRC and he said I should talk to you
about it. I actually pestered hpa about it already, sorry :).
So I've been looking
On Fri, Mar 01, 2013 at 02:58:56PM -0800, H. Peter Anvin wrote:
We seem to have a few options:
1. We could always map 1:1, with the EFI mappings being in the user
part of the virtual address space. This MAY be what Windows does
already. Some Apple platforms are known to fail in this
Just commenting on this one for now, the rest tomorrow cuz I'm half
asleep.
On Fri, Mar 01, 2013 at 11:30:25PM +, David Woodhouse wrote:
The other option, for the long term, is to fix the damn firmware to
allow SetVirtualAddressMap to be called more than once. It was stupid
for it to be a
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
What appears to be happening is that your the EFI runtime services
code is calling into the EFI boot services code, which is definitely
a bug in your firmware because we're at runtime, but we've seen
other machines that do similar
From: Borislav Petkov b...@suse.de
Hi all,
this one is 64-bit only for now and it has been tested only in kvm with
OVMF.
Keeping in mind the ihnerent efi b0rkedness left and right, I'd like to
be very cautious and conservative with this and not hurry anything until
it has been actually very
From: Borislav Petkov b...@suse.de
... to void * like the boot services and lose all the void * casts. No
functionality change.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/boot/compressed/eboot.c | 2 +-
arch/x86/include/asm/efi.h | 28 ++--
include
From: Borislav Petkov b...@suse.de
Add the ability to map pages in an arbitrary pgd.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/include/asm/pgtable_types.h | 3 +-
arch/x86/mm/pageattr.c | 80
2 files changed, 65 insertions
From: Borislav Petkov b...@suse.de
Due to the braindead design of EFI, we cannot map runtime services more
than once for the duration of a booted system. Thus, if we want to use
EFI runtime services in a kexec'ed kernel, maybe the only possible and
sensible approach would be to map them 1:1 so
On Sun, Jun 02, 2013 at 11:56:20PM +0100, Matthew Garrett wrote:
I've just run Windows 8 under a hacked up copy of OVMF that dumps
the data passed to SetVirtualAddressMap. It seems that Windows *is*
mapping the runtime services to higher addresses - so presumably the
1:1 mapping is in addition
On Thu, Jun 06, 2013 at 06:50:52PM +0100, Matthew Garrett wrote:
On Thu, Jun 06, 2013 at 03:26:03PM +0200, Borislav Petkov wrote:
This would break the Macs, remember?
I think the Macs will be fine as long as we're passing the high mappings
into SetVirtualAddressMap().
Right, on those
On Thu, Jun 06, 2013 at 12:28:20PM -0700, H. Peter Anvin wrote:
Or we could materialize mappings for this specific PGD. However,
adding a read of %cr3 in __do_page_fault sounds expensive.
Yes, I think we want to make sure all mappings are there when we do an
EFI runtime call so that we never
On Thu, Jun 06, 2013 at 08:35:48PM +0100, Matthew Garrett wrote:
No, I think that's the wrong thing to do. We should set up the current
mappings and the 1:1 mappings, and pass the current mappings through
SetVirtualAddressMap(). That matches the behaviour of Windows.
And when do we use the 1:1
On Thu, Jun 06, 2013 at 08:54:50PM +0100, Matthew Garrett wrote:
We want both to be available when we're making the call, but I think
we should probably enter via the high addresses. The only reason we're
doing this at all is that some systems don't update all of their
pointers from physical
On Thu, Jun 06, 2013 at 09:18:28PM +0100, Matthew Garrett wrote:
kexec seems like a lower priority than compatibility. Perhaps keep the
efi argument for people who want to use kexec?
This is what I currently have in the code: if you boot with efi=1:1_map,
you get them.
hpa suggested
On Thu, Jun 06, 2013 at 09:30:57PM +0100, Matthew Garrett wrote:
Well, we want the 1:1 mappings to exist all the time. The only
thing the option should change is whether they're passed to
SetVirtualAddressMap() or not.
But can you call them even if they haven't been passed through
On Thu, Jun 06, 2013 at 09:50:57PM +0100, Matthew Garrett wrote:
What do you mean by call them? I don't think we ever want to call by
physical address, other than maybe in the kexec case. The only reason
we really care about the physical addresses being mapped 1:1 is that
some pointers may not
On Thu, Jun 06, 2013 at 12:38:10PM -0700, H. Peter Anvin wrote:
On 06/06/2013 12:36 PM, Borislav Petkov wrote:
On Thu, Jun 06, 2013 at 12:28:20PM -0700, H. Peter Anvin wrote:
Or we could materialize mappings for this specific PGD. However,
adding a read of %cr3 in __do_page_fault sounds
On Tue, Jun 11, 2013 at 07:49:12AM +0100, Matt Fleming wrote:
OK, I chickened out of sending this in my latest pull request
after reading Linus' -rc5 email about him not wanting to see any
non-critical changes. I've stuck it in the 'next' branch with the rest
of the stuff for v3.11.
Yep, did
From: Borislav Petkov b...@suse.de
Hi all,
this is just a snapshot of the current state of affairs. The patchset
starts to boot successfully on real hardware now but we're far away from
the coverage we'd like to have before we even consider upstreaming it.
And yes, considering the sick f*ck EFI
From: Borislav Petkov b...@suse.de
.. for passing miscellaneous options from the kernel command line.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/platform/efi/efi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86
From: Borislav Petkov b...@suse.de
... to void * like the boot services and lose all the void * casts. No
functionality change.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/boot/compressed/eboot.c | 2 +-
arch/x86/include/asm/efi.h | 28 ++--
include
From: Borislav Petkov b...@suse.de
Add the ability to map pages in an arbitrary pgd.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/include/asm/pgtable_types.h | 3 +-
arch/x86/mm/pageattr.c | 82
2 files changed, 67 insertions
From: Borislav Petkov b...@suse.de
Due to the braindead design of EFI, we cannot map runtime services more
than once for the duration of a booted system. Thus, if we want to use
EFI runtime services in a kexec'ed kernel, maybe the only possible and
sensible approach would be to map them 1:1 so
On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote:
I hope making it a weird boot option is not the end plan, there's
little point in _not_ enabling 1:1 mappings by default eventually:
the 1:1 mapping is supposed to emulate a Windows compatible EFI
environment better and is expected
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote:
Do we know why?
Well, according to mjg59 some Macs break if we don't give them a map
which uses high addresses.
I can imagine flipping the meaning of this option to be on by default
and efi=no_11_map to disable the 1:1 map for those
On Wed, Jun 19, 2013 at 05:08:04PM +0100, Matthew Garrett wrote:
But, as always, the only reliable thing to do here is to behave as
much like Windows as possible. Which means performing the 1:1 mapping
but maintaining the high mapping, and passing the high values via
SetVirtualAddressMap.
We
On Wed, Jun 19, 2013 at 05:48:22PM +0100, Matthew Garrett wrote:
Ok, so it sounds like we want to *always* create both mappings but,
depending on what we want, to shove down SetVirtualAddressMap a
different set. And the 1:1 map will be the optional one which we give
SetVirtualAddressMap
On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote:
On 06/19/2013 08:02 AM, Borislav Petkov wrote:
And yet there are the Macs which reportedly cannot stomach this.
No, the reports are that if you use the 1:1 map as the primary address
on Macs the drivers fail... not that you
On Wed, Jun 19, 2013 at 12:38:24PM -0500, H. Peter Anvin wrote:
I thought that was the plan?
Well, currently if I'm booted with efi=1:1_map I'm creating only the
1:1 mapping in -trampoline_pgd and switching the pagetable only then.
Otherwise, I'm using the high, ioremapped mappings - i.e., what
On Thu, Jun 20, 2013 at 11:22:37AM +0200, Ingo Molnar wrote:
Cool - and supposedly this will work in a Mac environment as well? Would
be very nice to avoid fundamentally fragile system specific quirks for
something as fundamental as the EFI runtime memory mapping model ...
Apple is
On Thu, Jun 20, 2013 at 05:54:26PM +0100, Matthew Garrett wrote:
On Thu, Jun 20, 2013 at 09:46:15AM -0700, James Bottomley wrote:
Unless you can think of the way out of this, we seem to have the stark
choice of behave like windows or allow kexec. For the server market,
kexec wins, so
On Thu, Jun 20, 2013 at 06:12:10PM +0100, Matthew Garrett wrote:
On Thu, Jun 20, 2013 at 07:01:24PM +0200, Borislav Petkov wrote:
If we can detect the Macs, we can make this decision automatic. And
since no Mac boots windoze, a single DMI check of the sort if (Mac)
should suffice.
Yes
On Thu, Jun 20, 2013 at 07:10:15PM +0100, Matthew Garrett wrote:
Because Windows passes high addresses to SetVirtualAddressMap(), and
because if you can imagine firmware developers getting it wrong then
firmware developers will have got it wrong.
Can we reversely assume that if we'd used fixed
On Thu, Jun 20, 2013 at 07:17:31PM +0100, Matthew Garrett wrote:
On Thu, Jun 20, 2013 at 08:14:45PM +0200, Borislav Petkov wrote:
On Thu, Jun 20, 2013 at 07:10:15PM +0100, Matthew Garrett wrote:
Because Windows passes high addresses to SetVirtualAddressMap(), and
because if you can
On Fri, Jun 21, 2013 at 03:05:30AM -0700, H. Peter Anvin wrote:
If you cap it you are basically imposing a constraint on the firmware
and may not run properly (or at least have to turn off EFI runtime
calls with all that implies.)
I don't want to cap EFI just for the fun of it but rather set a
On Wed, Jun 26, 2013 at 02:54:17PM +0100, Matt Fleming wrote:
On Wed, 26 Jun, at 02:46:09PM, Grant Likely wrote:
Eventually we'll need to look at how this interacts with kexec. A
kexec'd kernel will need to use the mapping already chosen by a
previous kernel, but that's an issue for another
Hi guys,
so I'm seeing this funny thing where an EFI region changes when we enter
efi_enter_virtual_mode when booting with edk2 on kvm. Here's the diff:
--- before 2013-07-31 22:20:52.316039492 +0200
+++ after 2013-07-31 22:21:30.960731706 +0200
@@ -9,7 +9,7 @@ efi: mem07: type=2,
On Mon, Aug 05, 2013 at 01:27:16PM +0200, Laszlo Ersek wrote:
--- before 2013-07-31 22:20:52.316039492 +0200
+++ after 2013-07-31 22:21:30.960731706 +0200
@@ -9,7 +9,7 @@ efi: mem07: type=2, attr=0xf, range=[0x0
efi: mem08: type=7, attr=0xf,
On Mon, Aug 05, 2013 at 03:39:31PM +0200, Laszlo Ersek wrote:
My question was: is my understanding correct that you only see this
problem with -enable-kvm? Because,
On 08/01/13 18:49, Borislav Petkov wrote:
so I'm seeing this funny thing where an EFI region changes when we
enter
On Mon, Aug 05, 2013 at 04:27:44PM +0200, Laszlo Ersek wrote:
I wouldn't call the design of SetVirtualAddressMap() braindead.
Ok, I've always wondered and you could probably shed some light on the
matter: why is SetVirtualAddressMap() a call-once only? Why can't I
simply call it again and update
On Mon, Aug 05, 2013 at 06:41:20PM +0200, Laszlo Ersek wrote:
I didn't realize the timestamps survive kexec. (As far as I remember
the kernels I played with kexec on didn't have the automatic
timestamps yet in dmesg, but I might have messed up just as well...)
No, no, no, kexec is not involved
On Mon, Aug 05, 2013 at 08:50:17AM -0700, Andrew Fish wrote:
AFAICT EFI pre-dates kexec merge into mainline by a number of years as
SetVirtualaddressMap() was part of EFI 1.0 (previous millennium)
Ok, fair enough.
The EFI to UEFI conversion was placing EFI 1.10 into an industry
standard,
On Mon, Aug 05, 2013 at 02:37:08PM -0700, H. Peter Anvin wrote:
All of this would be a non-problem if there weren't buggy
implementations which can't run *without* SetVirtualAddressMap().
Oh, you mean, if we were to call the runtime services through their
physical addresses?
--
Regards/Gruss,
On Mon, Aug 05, 2013 at 11:26:46PM +0200, Laszlo Ersek wrote:
What happens if you pass memblock=debug on the kernel command line
(see early_memblock() in mm/memblock.c)?
(I just tried it in my Fedora 19 guest, and it in fact produced the message
[0.00] efi: Could not reserve boot
Reported-and-tested-by: Borislav Petkov b...@suse.de
Great, thanks for this.
I guess we got that out of the way too. I finally can concentrate on my
patches again :-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote:
Hm. It would be really useful to have a kernel build option which
*disables* all the workarounds we've ever put in for broken firmware.
Yeah, cool!
I wonder if we could reach a high double-digit percentage of machines
not
From: Borislav Petkov b...@suse.de
We try to free the pagetable pages once we've unmapped our portion.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/mm/pageattr.c | 94 +-
1 file changed, 93 insertions(+), 1 deletion(-)
diff --git
From: Borislav Petkov b...@suse.de
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 b...@suse.de
From: Borislav Petkov b...@suse.de
... and use the good old standard defines which we all know. Also,
simplify math to shift by PAGE_SHIFT instead of multiplying by
PAGE_SIZE.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/boot/compressed/eboot.c | 12 ++--
arch/x86/boot
From: Borislav Petkov b...@suse.de
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 b...@suse.de
---
arch/x86/mm/pageattr.c | 53
From: Borislav Petkov b...@suse.de
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
From: Borislav Petkov b...@suse.de
... and lose one #ifdef .. #endif sandwich.
Signed-off-by: Borislav Petkov b...@suse.de
---
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
From: Borislav Petkov b...@suse.de
Hi all,
here's finally a new version of the runtime services VA mapping patchset
which hopefully implements hpa's idea of statically mapping EFI runtime
regions in a top-down manner starting at -4Gb virtual.
We're also using a different pagetable so
From: Borislav Petkov b...@suse.de
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 b...@suse.de
---
arch/x86/mm/pageattr.c | 36 ++--
1 file changed, 26
From: Borislav Petkov b...@suse.de
Handle last level by unconditionally writing the PTEs into the PTE page
while paying attention to the NX bit.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/mm/pageattr.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion
From: Borislav Petkov b...@suse.de
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
On Fri, Sep 20, 2013 at 03:29:04PM +0800, Dave Young wrote:
Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But
it immediately reboot on my Thinkpad T420. Unfortunately there's no
way to debug this very early problem because there's no serial port
also earlyprintk does not
On Fri, Sep 20, 2013 at 04:19:40PM +0800, Dave Young wrote:
Actually the ovmf testing is qemu-system-x86_64 -kernel , boot from grub
fails as well. Nothing printed on serial. I guess '-kernel' is using efi stub
to boot?
Yes.
Which OVMF are you using? Mine is pretty recent: svn revision 14530
On Fri, Sep 20, 2013 at 10:49:13AM +0100, Matt Fleming wrote:
/home/build/git/efi/arch/x86/platform/efi/efi.c: In function ‘__map_region’:
/home/build/git/efi/arch/x86/platform/efi/efi.c:753:24: error: ‘struct
real_mode_header’ has no member named ‘trampoline_pgd’
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
On Sat, Sep 21, 2013 at 05:21:39PM +0200, Leif Lindholm wrote:
It will probably not be a problem on the stub side, and it's not used
in many places but it would break efi_lookup_mapped_address(),
efi_range_is_wc() and memrange_efi_to_native() for use by arm64.
At least the first of these
On Sat, Sep 21, 2013 at 05:41:43PM +0200, Borislav Petkov wrote:
On Sat, Sep 21, 2013 at 05:21:39PM +0200, Leif Lindholm wrote:
It will probably not be a problem on the stub side, and it's not used
in many places but it would break efi_lookup_mapped_address(),
efi_range_is_wc
On Sat, Sep 21, 2013 at 06:01:21PM +0200, Leif Lindholm wrote:
Correct. On arm64, EFI_PAGE_SIZE will be 4K, and PAGE_SIZE can be 4K
or 64K, with at least Fedora opting for 64K.
Hm, ok, it looks like we want to keep EFI_PAGE_SIZE.
Oh well.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a
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 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 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 30
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 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
From: Borislav Petkov b...@suse.de
... for passing miscellaneous options and chicken bits from the command
line.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/platform/efi/efi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86
On Thu, Oct 10, 2013 at 04:14:34PM +0800, Dave Young wrote:
Even though I still have no idea why kernel text overlap with efi boot
region, anyway map the un-overlapped part is necessary though.
I can post the kexec related patches after your mapping patches settle
down
Right, settle down
On Fri, Oct 11, 2013 at 02:24:37PM +0800, Dave Young wrote:
But for current implementation from Boris, getting same mapping
between diffrent kernel depends on same md order (same start and
size for each one) How about using this mapping solution but at the
same time for kexec kernel we also
On Sat, Oct 12, 2013 at 11:13:08AM +0100, Matt Fleming wrote:
On Sat, 12 Oct, at 03:54:44PM, Dave Young wrote:
Boris:
For the boot service region overlapping problem I have another idea,
how about modify your mapping code to always mapping the RUNTIME region
(non boot service region)
On Sun, Oct 13, 2013 at 11:11:27AM +0800, Dave Young wrote:
Boris, I think we have got the agreement about passing setup_data?
Yes.
Basically, we want to start with what hpa suggested and see where it
gets us:
http://marc.info/?l=linux-kernelm=138006799131051
I think it should be on top of
On Mon, Oct 21, 2013 at 08:47:39PM +0800, Dave Young wrote:
What's the status of this series?
They should appear at some point in Matt's efi-next branch, I think.
I need below patch for mapping to fixed virt addr passed
from 1st kernel.
You need this to map the runtime regions in the kexec
On Mon, Oct 21, 2013 at 11:04:26PM +0800, Dave Young wrote:
You need this to map the runtime regions in the kexec kernel, right?
Please write that in the commit message.
Yes, will do
Ok, but but, why doesn't the normal code path in efi_enter_virtual_mode
work anymore? I mean, why do you
On Wed, Oct 23, 2013 at 10:17:31AM +0800, Dave Young wrote:
The reason is that I only pass runtime regions from 1st kernel to
kexec kernel, your efi mapping function uses the region size to
determin the virtual address from top to down. Because the passed-in
md ranges in kexec kernel are
On Wed, Oct 23, 2013 at 08:51:31PM +0800, Dave Young wrote:
In kexed 2nd kernel, phys_start_b need to be mapped to virt_start_b
Simply use efi_map_region from your patch does not work because it
will map phys_start_b to a different virt address, isn't it?
Oh ok, in the second kernel we're not
: 100 md start: 80 md size: 80
Signed-off-by: Dave Young dyo...@redhat.com
Acked-by: Borislav Petkov b...@suse.de
Btw, Matt, this being a bugfix and all, shouldn't it be tagged for
stable?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine
On Sun, Oct 27, 2013 at 11:47:14AM +0800, dyo...@redhat.com wrote:
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_remap_region to remapping it directly without
calculate the virt addr from efi_va.
The md is passed in from 1st kernel, the virtual addr is
saved
On Mon, Oct 28, 2013 at 09:18:24AM +0800, Dave Young wrote:
There should be some people see below message with non-kexec kernel:
Could not reserve boot range ...
I can find one other report like that: https://lkml.org/lkml/2013/7/16/309
[0.00] efi: Could not reserve boot range
On Sun, Oct 27, 2013 at 11:47:16AM +0800, dyo...@redhat.com wrote:
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
Signed-off-by: Dave Young dyo...@redhat.com
---
arch/x86/platform/efi/efi.c | 83
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 in
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.
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
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 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 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
From: Borislav Petkov b...@suse.de
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
From: Borislav Petkov b...@suse.de
Handle PMD-level mappings the same as PUD ones.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/mm/pageattr.c | 82 +-
1 file changed, 81 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/pageattr.c
From: Borislav Petkov b...@suse.de
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 b...@suse.de
From: Borislav Petkov b...@suse.de
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 b...@suse.de
---
arch/x86/mm/pageattr.c | 36 ++--
1 file changed, 26
From: Borislav Petkov b...@suse.de
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
From: Borislav Petkov b...@suse.de
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
From: Borislav Petkov b...@suse.de
Handle last level by unconditionally writing the PTEs into the PTE page
while paying attention to the NX bit.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/mm/pageattr.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion
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.
--
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 to
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
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 service
1 - 100 of 494 matches
Mail list logo
