Re: [PATCH v2 0/5] mm: support parallel free of memory

On Fri, Mar 17, 2017 at 10:21:58AM +0800, Aaron Lu wrote: > On Thu, Mar 16, 2017 at 02:38:44PM -0500, Alex Thorlton wrote: > > On Wed, Mar 15, 2017 at 04:59:59PM +0800, Aaron Lu wrote: > > > v2 changes: Nothing major, only minor ones. > > > - rebased on top of v4.11

Re: [PATCH v2 0/5] mm: support parallel free of memory

On Fri, Mar 17, 2017 at 10:21:58AM +0800, Aaron Lu wrote: > On Thu, Mar 16, 2017 at 02:38:44PM -0500, Alex Thorlton wrote: > > On Wed, Mar 15, 2017 at 04:59:59PM +0800, Aaron Lu wrote: > > > v2 changes: Nothing major, only minor ones. > > > - rebased on top of v4.11

Re: [PATCH v2 0/5] mm: support parallel free of memory

On Wed, Mar 15, 2017 at 04:59:59PM +0800, Aaron Lu wrote: > v2 changes: Nothing major, only minor ones. > - rebased on top of v4.11-rc2-mmotm-2017-03-14-15-41; > - use list_add_tail instead of list_add to add worker to tlb's worker >list so that when doing flush, the first queued worker gets

Re: [PATCH v2 0/5] mm: support parallel free of memory

On Wed, Mar 15, 2017 at 04:59:59PM +0800, Aaron Lu wrote: > v2 changes: Nothing major, only minor ones. > - rebased on top of v4.11-rc2-mmotm-2017-03-14-15-41; > - use list_add_tail instead of list_add to add worker to tlb's worker >list so that when doing flush, the first queued worker gets

[PATCH 2/2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

this callback. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Suggested-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Reviewed-by: Juergen Gross <jgr...@suse.com> Cc: Russ Anderson <r...@sgi.com> Cc: David Vrabel <david.vra...@citrix.com> Cc: Ingo Molnar <mi...@r

[PATCH 2/2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

this callback. Signed-off-by: Alex Thorlton Suggested-by: Boris Ostrovsky Reviewed-by: Juergen Gross Cc: Russ Anderson Cc: David Vrabel Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Denys Vlasenko Cc: Boris Ostrovsky Cc: x...@kernel.org Cc: xen-de...@lists.xenproject.org

[RFC PATCH v3] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

/comments! Alex Thorlton (2): x86: Make E820_X_MAX unconditionally larger than E820MAX xen/x86: Increase xen_e820_map to E820_X_MAX possible entries arch/x86/include/asm/e820.h | 12 arch/x86/xen/setup.c| 6 +++--- 2 files changed, 11 insertions(+), 7 deletions

[PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

the XENMEM_machine_memory_map hypercall can produce an e820 map larger than 128 entries, even on systems where the original e820 table was quite a bit smaller than that, depending on how many IOAPICs are installed on the system. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Suggested-by: Ingo

[RFC PATCH v3] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

/comments! Alex Thorlton (2): x86: Make E820_X_MAX unconditionally larger than E820MAX xen/x86: Increase xen_e820_map to E820_X_MAX possible entries arch/x86/include/asm/e820.h | 12 arch/x86/xen/setup.c| 6 +++--- 2 files changed, 11 insertions(+), 7 deletions

[PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

the XENMEM_machine_memory_map hypercall can produce an e820 map larger than 128 entries, even on systems where the original e820 table was quite a bit smaller than that, depending on how many IOAPICs are installed on the system. Signed-off-by: Alex Thorlton Suggested-by: Ingo Molnar Cc: Russ Anderson

Re: [PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

On Wed, Nov 30, 2016 at 07:21:48AM +0100, Ingo Molnar wrote: > > * Alex Thorlton <athorl...@sgi.com> wrote: > > > It's really not necessary to limit E820_X_MAX to 128 in the non-EFI > > case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that > &

Re: [PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

On Wed, Nov 30, 2016 at 07:21:48AM +0100, Ingo Molnar wrote: > > * Alex Thorlton wrote: > > > It's really not necessary to limit E820_X_MAX to 128 in the non-EFI > > case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that > > E820_X_MAX is always at

[PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

the XENMEM_machine_memory_map hypercall can produce an e820 map larger than 128 entries, even on systems where the original e820 table was quite a bit smaller than that, depending on how many IOAPICs are installed on the system. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Suggested-by: Ingo

[PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

the XENMEM_machine_memory_map hypercall can produce an e820 map larger than 128 entries, even on systems where the original e820 table was quite a bit smaller than that, depending on how many IOAPICs are installed on the system. Signed-off-by: Alex Thorlton Suggested-by: Ingo Molnar Cc: Russ Anderson

[PATCH 2/2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

this callback. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Suggested-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: Russ Anderson <r...@sgi.com> Cc: David Vrabel <david.vra...@citrix.com> Cc: Ingo Molnar <mi...@redhat.com> Cc: Juergen Gross <jgr...@suse.com> Cc:

[PATCH 2/2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

this callback. Signed-off-by: Alex Thorlton Suggested-by: Boris Ostrovsky Cc: Russ Anderson Cc: David Vrabel Cc: Ingo Molnar Cc: Juergen Gross Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Denys Vlasenko Cc: Boris Ostrovsky Cc: x...@kernel.org Cc: xen-de...@lists.xenproject.org --- ar

[RFC PATCH v2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

that others can give! - Alex Alex Thorlton (2): x86: Make E820_X_MAX unconditionally larger than E820MAX xen/x86: Increase xen_e820_map to E820_X_MAX possible entries arch/x86/include/asm/e820.h | 8 +++- arch/x86/xen/setup.c| 6 +++--- 2 files changed, 6 insertions(+), 8 deletions

[RFC PATCH v2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

that others can give! - Alex Alex Thorlton (2): x86: Make E820_X_MAX unconditionally larger than E820MAX xen/x86: Increase xen_e820_map to E820_X_MAX possible entries arch/x86/include/asm/e820.h | 8 +++- arch/x86/xen/setup.c| 6 +++--- 2 files changed, 6 insertions(+), 8 deletions

Re: [tip:x86/urgent] x86/apic/uv: Silence a shift wrapping warning

lain that 1 << 63 will wrap so I have changed it to > 1ULL << m_io. > > This code is over three years old so presumably the bug doesn't happen > very frequently in real life or someone would have complained by now. > > Signed-off-by: Dan Carpenter <dan.carpen..

Re: [tip:x86/urgent] x86/apic/uv: Silence a shift wrapping warning

> 1ULL << m_io. > > This code is over three years old so presumably the bug doesn't happen > very frequently in real life or someone would have complained by now. > > Signed-off-by: Dan Carpenter > Cc: Alex Thorlton Acked-by: Alex Thorlton - Alex

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

On Tue, Nov 15, 2016 at 10:55:49AM +0100, Juergen Gross wrote: > I'd go with the new error code. What about E2BIG or ENOSPC? > > I think the hypervisor should fill in the number of entries required > in this case. > > In case nobody objects I can post patches for this purpose (both Xen > and

Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

On Tue, Nov 15, 2016 at 10:55:49AM +0100, Juergen Gross wrote: > I'd go with the new error code. What about E2BIG or ENOSPC? > > I think the hypervisor should fill in the number of entries required > in this case. > > In case nobody objects I can post patches for this purpose (both Xen > and

[RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

, there isn't exactly a "more appropriate" macro/variable to use, so this may not really be an issue. Any input on the patch, or the questions I've raised above is greatly appreciated! - Alex Alex Thorlton (1): xen/x86: Increase xen_e820_map to E820_X_MAX possible entries arch/x86/x

[RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

, there isn't exactly a "more appropriate" macro/variable to use, so this may not really be an issue. Any input on the patch, or the questions I've raised above is greatly appreciated! - Alex Alex Thorlton (1): xen/x86: Increase xen_e820_map to E820_X_MAX possible entries arch/x86/x

[tip:x86/urgent] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

Commit-ID: caef78b6cdeddf4ad364f95910bba6b43b8eb9bf Gitweb: http://git.kernel.org/tip/caef78b6cdeddf4ad364f95910bba6b43b8eb9bf Author: Alex Thorlton <athorl...@sgi.com> AuthorDate: Wed, 19 Oct 2016 20:48:51 -0500 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu, 20

[tip:x86/urgent] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

Commit-ID: caef78b6cdeddf4ad364f95910bba6b43b8eb9bf Gitweb: http://git.kernel.org/tip/caef78b6cdeddf4ad364f95910bba6b43b8eb9bf Author: Alex Thorlton AuthorDate: Wed, 19 Oct 2016 20:48:51 -0500 Committer: Ingo Molnar CommitDate: Thu, 20 Oct 2016 08:47:58 +0200 x86/platform/UV: Fix

[PATCH v2] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

is set, we fall back to using our old callback method, which uses efi_call directly on the __va of our function pointer. v2: Invert if-statement and add unlikely() hint. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Mike Travis <tra...@sgi.com> Cc: Russ Anderson <r...@s

[PATCH v2] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

is set, we fall back to using our old callback method, which uses efi_call directly on the __va of our function pointer. v2: Invert if-statement and add unlikely() hint. Signed-off-by: Alex Thorlton Cc: Mike Travis Cc: Russ Anderson Cc: Dimitri Sivanich Cc: Thomas Gleixner Cc: Ingo Molnar

Re: [PATCH] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

On Wed, Oct 19, 2016 at 12:32:00PM +0100, Matt Fleming wrote: > Could you please invert the conditional? I had to read it 3 times to > make sure it was correct given the comment that precedes it. E.g. this > is preferable, > > if (efi_enabled(EFI_OLD_MEMMAP)) > ret =

Re: [PATCH] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

On Wed, Oct 19, 2016 at 12:32:00PM +0100, Matt Fleming wrote: > Could you please invert the conditional? I had to read it 3 times to > make sure it was correct given the comment that precedes it. E.g. this > is preferable, > > if (efi_enabled(EFI_OLD_MEMMAP)) > ret =

[PATCH] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

is set, we fall back to using our old callback method, which uses efi_call directly on the __va of our function pointer. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Mike Travis <tra...@sgi.com> Cc: Russ Anderson <r...@sgi.com> Cc: Dimitri Sivanich <sivan...@sgi.com>

[PATCH] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

is set, we fall back to using our old callback method, which uses efi_call directly on the __va of our function pointer. Signed-off-by: Alex Thorlton Cc: Mike Travis Cc: Russ Anderson Cc: Dimitri Sivanich Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Matt Flemi

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote: > > > Why do you guys need the physical mapping all of a sudden? > > > > It's not that we need it all of the sudden, necessarily, it's just that > > we've had to make other changes to make things work with the new, > > (almost)

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote: > > > Why do you guys need the physical mapping all of a sudden? > > > > It's not that we need it all of the sudden, necessarily, it's just that > > we've had to make other changes to make things work with the new, > > (almost)

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Tue, Aug 16, 2016 at 07:50:10AM +0200, Borislav Petkov wrote: > On Mon, Aug 15, 2016 at 01:47:31PM -0500, Alex Thorlton wrote: > > The only thing we're adding here is the physical mappings, to match > > what is availble in the primary kernel. > > I can see what it does -

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Tue, Aug 16, 2016 at 07:50:10AM +0200, Borislav Petkov wrote: > On Mon, Aug 15, 2016 at 01:47:31PM -0500, Alex Thorlton wrote: > > The only thing we're adding here is the physical mappings, to match > > what is availble in the primary kernel. > > I can see what it does -

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Mon, Aug 15, 2016 at 05:07:09PM +0200, Borislav Petkov wrote: > On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote: > > (Cc'ing Boris and Dave) > > > > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote: > > > This is a simple change to add in

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Mon, Aug 15, 2016 at 05:07:09PM +0200, Borislav Petkov wrote: > On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote: > > (Cc'ing Boris and Dave) > > > > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote: > > > This is a simple change to add in

[tip:efi/urgent] x86/platform/uv: Skip UV runtime services mapping in the efi_runtime_disabled case

Commit-ID: f72075c9eda8a43aeea2f9dbb8d187afd4a76f0b Gitweb: http://git.kernel.org/tip/f72075c9eda8a43aeea2f9dbb8d187afd4a76f0b Author: Alex Thorlton <athorl...@sgi.com> AuthorDate: Thu, 11 Aug 2016 11:41:59 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu, 11

[tip:efi/urgent] x86/platform/uv: Skip UV runtime services mapping in the efi_runtime_disabled case

Commit-ID: f72075c9eda8a43aeea2f9dbb8d187afd4a76f0b Gitweb: http://git.kernel.org/tip/f72075c9eda8a43aeea2f9dbb8d187afd4a76f0b Author: Alex Thorlton AuthorDate: Thu, 11 Aug 2016 11:41:59 +0100 Committer: Ingo Molnar CommitDate: Thu, 11 Aug 2016 13:55:36 +0200 x86/platform/uv: Skip UV

funkier linuxdev mail test

Maybe this time?

funkier linuxdev mail test

Maybe this time?

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Fri, Aug 05, 2016 at 06:59:35PM -0500, Alex Thorlton wrote: > This is a simple change to add in the physical mappings as well as the > virtual mappings in efi_map_region_fixed. The motivation here is to > get access to EFI runtime code that is only available via the 1:1 > mappings

Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Fri, Aug 05, 2016 at 06:59:35PM -0500, Alex Thorlton wrote: > This is a simple change to add in the physical mappings as well as the > virtual mappings in efi_map_region_fixed. The motivation here is to > get access to EFI runtime code that is only available via the 1:1 > mappings

[PATCH] Map in physical addresses in efi_map_region_fixed

__map_region that Boris put in efi_map_region in commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping"). Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Russ Anderson <r...@sgi.com> Cc: Dimitri Sivanich <sivan...@sgi.com> Cc: Mike Travis <tra.

[PATCH] Map in physical addresses in efi_map_region_fixed

__map_region that Boris put in efi_map_region in commit d2f7cbe7b26a ("x86/efi: Runtime services virtual mapping"). Signed-off-by: Alex Thorlton Cc: Russ Anderson Cc: Dimitri Sivanich Cc: Mike Travis Cc: Matt Fleming Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Pete

Re: [RFC PATCH] Fix EFI callbacks on UV during kexec

On Thu, Aug 04, 2016 at 10:25:32AM +0100, Matt Fleming wrote: > On Mon, 01 Aug, at 09:34:10AM, Alex Thorlton wrote: > > > > Hmm... That's a good point. It certainly would be nice for us to have > > those mappings in the kexec kernel, at least for the time being. If &

Re: [RFC PATCH] Fix EFI callbacks on UV during kexec

On Thu, Aug 04, 2016 at 10:25:32AM +0100, Matt Fleming wrote: > On Mon, 01 Aug, at 09:34:10AM, Alex Thorlton wrote: > > > > Hmm... That's a good point. It certainly would be nice for us to have > > those mappings in the kexec kernel, at least for the time being. If &

Re: [PATCH] Skip UV runtime services mapping in the efi_runtime_disabled case

On Mon, Aug 01, 2016 at 09:28:06AM -0500, Alex Thorlton wrote: > So, it definitely needs to go in for v4.8, but it's kind of a toss-up > for the older kernels. I'll discuss this with the other guys around > here to see what they think, and get back to you a bit later, if that's >

Re: [PATCH] Skip UV runtime services mapping in the efi_runtime_disabled case

On Mon, Aug 01, 2016 at 09:28:06AM -0500, Alex Thorlton wrote: > So, it definitely needs to go in for v4.8, but it's kind of a toss-up > for the older kernels. I'll discuss this with the other guys around > here to see what they think, and get back to you a bit later, if that's >

Re: [RFC PATCH] Fix EFI callbacks on UV during kexec

On Mon, Aug 01, 2016 at 02:39:26PM +0100, Matt Fleming wrote: > On Tue, 26 Jul, at 05:38:32PM, Alex Thorlton wrote: > > > > After investigating the problem here and figuring out the proper way to > > get the noefi parameter working again, I noticed that there appears to &

Re: [RFC PATCH] Fix EFI callbacks on UV during kexec

On Mon, Aug 01, 2016 at 02:39:26PM +0100, Matt Fleming wrote: > On Tue, 26 Jul, at 05:38:32PM, Alex Thorlton wrote: > > > > After investigating the problem here and figuring out the proper way to > > get the noefi parameter working again, I noticed that there appears to &

Re: [PATCH] Skip UV runtime services mapping in the efi_runtime_disabled case

On Mon, Aug 01, 2016 at 02:49:57PM +0100, Matt Fleming wrote: > On Tue, 26 Jul, at 05:38:33PM, Alex Thorlton wrote: > > This problem has actually been in the UV code for a while, but we didn't > > catch it until recently, because we had been relying on EFI_OLD_MEMMAP > >

Re: [PATCH] Skip UV runtime services mapping in the efi_runtime_disabled case

On Mon, Aug 01, 2016 at 02:49:57PM +0100, Matt Fleming wrote: > On Tue, 26 Jul, at 05:38:33PM, Alex Thorlton wrote: > > This problem has actually been in the UV code for a while, but we didn't > > catch it until recently, because we had been relying on EFI_OLD_MEMMAP > >

[PATCH] Skip UV runtime services mapping in the efi_runtime_disabled case

in uv_bios_init, we end up trying to do EFI runtime callbacks when we shouldn't be. This patch just adds a check for efi_runtime_disabled in uv_bios_init so that we don't map in uv_systab when runtime_disabled == true. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Russ Anderson <r...@sg

[PATCH] Skip UV runtime services mapping in the efi_runtime_disabled case

in uv_bios_init, we end up trying to do EFI runtime callbacks when we shouldn't be. This patch just adds a check for efi_runtime_disabled in uv_bios_init so that we don't map in uv_systab when runtime_disabled == true. Signed-off-by: Alex Thorlton Cc: Russ Anderson Cc: Mike Travis Cc: Matt Fleming Cc

[RFC PATCH] Fix EFI callbacks on UV during kexec

s as well as the virtual addresses in efi_map_region_fixed, but the more "correct" fix would be to update our system table pointer to its new virtual address during SetVirtualAddressMap. We intend to get that piece fixed up relatively soon, but haven't quite gotten around to it yet. Let

[RFC PATCH] Fix EFI callbacks on UV during kexec

s as well as the virtual addresses in efi_map_region_fixed, but the more "correct" fix would be to update our system table pointer to its new virtual address during SetVirtualAddressMap. We intend to get that piece fixed up relatively soon, but haven't quite gotten around to it yet. Let

[tip:efi/core] efi: Convert efi_call_virt() to efi_call_virt_pointer()

Commit-ID: 80e75596079f0a41f905836ad0ccaac68ba33612 Gitweb: http://git.kernel.org/tip/80e75596079f0a41f905836ad0ccaac68ba33612 Author: Alex Thorlton <athorl...@sgi.com> AuthorDate: Sat, 25 Jun 2016 08:20:27 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 27

[tip:efi/core] x86/efi: Update efi_thunk() to use the the arch_efi_call_virt*() macros

Commit-ID: 21f866257c7027f8f49bfde83f559f9e58f9ee93 Gitweb: http://git.kernel.org/tip/21f866257c7027f8f49bfde83f559f9e58f9ee93 Author: Alex Thorlton <athorl...@sgi.com> AuthorDate: Sat, 25 Jun 2016 08:20:29 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 27

[tip:efi/core] x86/uv: Update uv_bios_call() to use efi_call_virt_pointer()

Commit-ID: d1be84a232e359ca9456c63e72cb0082d68311b6 Gitweb: http://git.kernel.org/tip/d1be84a232e359ca9456c63e72cb0082d68311b6 Author: Alex Thorlton <athorl...@sgi.com> AuthorDate: Sat, 25 Jun 2016 08:20:28 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 27

[tip:efi/core] x86/efi: Update efi_thunk() to use the the arch_efi_call_virt*() macros

Commit-ID: 21f866257c7027f8f49bfde83f559f9e58f9ee93 Gitweb: http://git.kernel.org/tip/21f866257c7027f8f49bfde83f559f9e58f9ee93 Author: Alex Thorlton AuthorDate: Sat, 25 Jun 2016 08:20:29 +0100 Committer: Ingo Molnar CommitDate: Mon, 27 Jun 2016 13:06:57 +0200 x86/efi: Update efi_thunk

[tip:efi/core] x86/uv: Update uv_bios_call() to use efi_call_virt_pointer()

Commit-ID: d1be84a232e359ca9456c63e72cb0082d68311b6 Gitweb: http://git.kernel.org/tip/d1be84a232e359ca9456c63e72cb0082d68311b6 Author: Alex Thorlton AuthorDate: Sat, 25 Jun 2016 08:20:28 +0100 Committer: Ingo Molnar CommitDate: Mon, 27 Jun 2016 13:06:56 +0200 x86/uv: Update

[tip:efi/core] efi: Convert efi_call_virt() to efi_call_virt_pointer()

Commit-ID: 80e75596079f0a41f905836ad0ccaac68ba33612 Gitweb: http://git.kernel.org/tip/80e75596079f0a41f905836ad0ccaac68ba33612 Author: Alex Thorlton AuthorDate: Sat, 25 Jun 2016 08:20:27 +0100 Committer: Ingo Molnar CommitDate: Mon, 27 Jun 2016 13:06:56 +0200 efi: Convert

[PATCH 2/3] Update uv_bios_call to use efi_call_virt_pointer

mapped into the EFI page table. For now, we will use the physical address of the function directly, since that is mapped into the EFI page table. In the near future, we're going to get some code added in to properly update our function pointer to its virtual address during SetVirtualAddressMa

[PATCH 1/3] Convert efi_call_virt to efi_call_virt_pointer

es to efi.systab->runtime everywhere. Note that I also broke up the code in the efi_call_virt_pointer macro a bit in the process of moving it. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Matt Fleming <m...@codeblueprint.co.uk> Cc: Russ Anderson <r...@sgi.com> Cc: D

[PATCH 1/3] Convert efi_call_virt to efi_call_virt_pointer

es to efi.systab->runtime everywhere. Note that I also broke up the code in the efi_call_virt_pointer macro a bit in the process of moving it. Signed-off-by: Alex Thorlton Cc: Matt Fleming Cc: Russ Anderson Cc: Dimitri Sivanich Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc:

[PATCH 2/3] Update uv_bios_call to use efi_call_virt_pointer

mapped into the EFI page table. For now, we will use the physical address of the function directly, since that is mapped into the EFI page table. In the near future, we're going to get some code added in to properly update our function pointer to its virtual address during SetVirtualAddressMap.

[PATCHv2 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

c: Roy Franz <roy.fr...@linaro.org> Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: x...@kernel.org Alex Thorlton (3): Convert efi_call_virt to efi_call_virt_pointer Update uv_bios_call to use efi_call_virt_pointer Update efi_thunk to use the the arch_efi_call_vi

[PATCHv2 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

Cc: Roy Franz Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: x...@kernel.org Alex Thorlton (3): Convert efi_call_virt to efi_call_virt_pointer Update uv_bios_call to use efi_call_virt_pointer Update efi_thunk to use the the arch_efi_call_virt* macros arch/arm/incl

[PATCH 3/3] Update efi_thunk to use the the arch_efi_call_virt* macros

Currently, the efi_thunk macro has some semi-duplicated code in it that can be replaced with the arch_efi_call_virt_setup/teardown macros. This commit simply replaces the duplicated code with those macros. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Suggested-by: Matt Flem

[PATCH 3/3] Update efi_thunk to use the the arch_efi_call_virt* macros

Currently, the efi_thunk macro has some semi-duplicated code in it that can be replaced with the arch_efi_call_virt_setup/teardown macros. This commit simply replaces the duplicated code with those macros. Signed-off-by: Alex Thorlton Suggested-by: Matt Fleming Cc: Russ Anderson Cc: Dimitri

Re: [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 04:14:03PM -0500, Alex Thorlton wrote: > On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote: > > Unless I've missed it, I didn't see an explanation in the changelog of > > why it's OK to switch from using __va(tab->function) to tab->functio

Re: [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 04:14:03PM -0500, Alex Thorlton wrote: > On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote: > > Unless I've missed it, I didn't see an explanation in the changelog of > > why it's OK to switch from using __va(tab->function) to tab->functio

Re: [PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 09:19:49PM +0100, Matt Fleming wrote: > On Wed, 18 May, at 02:11:41PM, Alex Thorlton wrote: > > +#define arch_efi_call_virt(p, f, ...) > > \ > > +({

Re: [PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 09:19:49PM +0100, Matt Fleming wrote: > On Wed, 18 May, at 02:11:41PM, Alex Thorlton wrote: > > +#define arch_efi_call_virt(p, f, ...) > > \ > > +({

Re: [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote: > Unless I've missed it, I didn't see an explanation in the changelog of > why it's OK to switch from using __va(tab->function) to tab->function > directly, which presumably is a physical address. > > Was that intended? It was

Re: [PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote: > Unless I've missed it, I didn't see an explanation in the changelog of > why it's OK to switch from using __va(tab->function) to tab->function > directly, which presumably is a physical address. > > Was that intended? It was

Re: [PATCH 1/3] Convert efi_call_virt to efi_call_virt_generic

On Thu, Jun 02, 2016 at 04:41:14PM +0100, Matt Fleming wrote: > Oops, you're missing updates to the 32-bit version and ARM/arm64, > which results in this, > > drivers/firmware/efi/runtime-wrappers.c: In function ‘virt_efi_get_time’: > arch/x86/include/asm/efi.h:46:4: error: ‘efi_efi’ undeclared

Re: [PATCH 1/3] Convert efi_call_virt to efi_call_virt_generic

On Thu, Jun 02, 2016 at 04:41:14PM +0100, Matt Fleming wrote: > Oops, you're missing updates to the 32-bit version and ARM/arm64, > which results in this, > > drivers/firmware/efi/runtime-wrappers.c: In function ‘virt_efi_get_time’: > arch/x86/include/asm/efi.h:46:4: error: ‘efi_efi’ undeclared

Re: [RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

On Wed, May 18, 2016 at 02:11:38PM -0500, Alex Thorlton wrote: > Let me know what everybody thinks! I realized right as I sent these that I should've included prefixes on the individual patches. I have a feeling we'll need a v2 anyways, so I'll clean that up then. - Alex

[PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

ines booting, running properly, and able to execute our callbacks with 6+ arguments. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Matt Fleming <m...@codeblueprint.co.uk> Cc: Borislav Petkov <b...@suse.de> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@red

Re: [RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

On Wed, May 18, 2016 at 02:11:38PM -0500, Alex Thorlton wrote: > Let me know what everybody thinks! I realized right as I sent these that I should've included prefixes on the individual patches. I have a feeling we'll need a v2 anyways, so I'll clean that up then. - Alex

[PATCH 2/3] Update uv_bios_call to use efi_call_virt_generic

ines booting, running properly, and able to execute our callbacks with 6+ arguments. Signed-off-by: Alex Thorlton Cc: Matt Fleming Cc: Borislav Petkov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Mike Travis Cc: Russ Anderson Cc: Dimitri Sivanich Cc: x...@kernel.org Cc: l

[PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

-think things a bit. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Matt Fleming <m...@codeblueprint.co.uk> Cc: Borislav Petkov <b...@suse.de> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zyt

[RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: Mike Travis <tra...@sgi.com> Cc: Russ Anderson <r...@sgi.com> Cc: Dimitri Sivanich <sivan...@sgi.com> Cc: x...@kernel.org Cc: linux-...@vger.kernel.org Alex Thorlton (3): Convert efi_call_virt t

[PATCH 3/3] Update efi_thunk to use efi_call_virt_generic

-think things a bit. Signed-off-by: Alex Thorlton Cc: Matt Fleming Cc: Borislav Petkov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Mike Travis Cc: Russ Anderson Cc: Dimitri Sivanich Cc: x...@kernel.org Cc: linux-...@vger.kernel.org --- arch/x86/include/as

[RFC PATCH 0/3] x86/UV, x86/efi: Re-factor efi_call_virt for general use

c: Dimitri Sivanich Cc: x...@kernel.org Cc: linux-...@vger.kernel.org Alex Thorlton (3): Convert efi_call_virt to efi_call_virt_generic Update uv_bios_call to use efi_call_virt_generic Update efi_thunk to use efi_call_virt_generic arch/x86/include/asm/efi.h | 51

[PATCH 1/3] Convert efi_call_virt to efi_call_virt_generic

es to efi.systab->runtime everywhere. Note that I also broke up the code in the efi_call_virt_generic macro a bit in the process of moving it. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Matt Fleming <m...@codeblueprint.co.uk> Cc: Borislav Petkov <b...@suse.de> Cc: Th

[PATCH 1/3] Convert efi_call_virt to efi_call_virt_generic

es to efi.systab->runtime everywhere. Note that I also broke up the code in the efi_call_virt_generic macro a bit in the process of moving it. Signed-off-by: Alex Thorlton Cc: Matt Fleming Cc: Borislav Petkov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Mike

Re: [PATCH 1/2] Create UV efi_call macros

On Tue, May 17, 2016 at 01:11:22PM +0100, Matt Fleming wrote: > On Mon, 16 May, at 05:58:40PM, Alex Thorlton wrote: > > > > I was simply re-using the efi_call implementation. Boris suggested that > > I re-write this using the efi_call_virt macro, so I just went with t

Re: [PATCH 1/2] Create UV efi_call macros

On Tue, May 17, 2016 at 01:11:22PM +0100, Matt Fleming wrote: > On Mon, 16 May, at 05:58:40PM, Alex Thorlton wrote: > > > > I was simply re-using the efi_call implementation. Boris suggested that > > I re-write this using the efi_call_virt macro, so I just went with t

Re: [PATCH 1/2] Create UV efi_call macros

On Thu, May 12, 2016 at 10:17:39AM +0200, Ingo Molnar wrote: > > Fine by me, although having a newline after arch_efi_call_virt_setup() > > but not before arch_efi_call_virt_teardown() seems rather arbitrary > > It's an oversight! :-) > > #define efi_call_virt(f, args...)

Re: [PATCH 1/2] Create UV efi_call macros

On Thu, May 12, 2016 at 10:17:39AM +0200, Ingo Molnar wrote: > > Fine by me, although having a newline after arch_efi_call_virt_setup() > > but not before arch_efi_call_virt_teardown() seems rather arbitrary > > It's an oversight! :-) > > #define efi_call_virt(f, args...)

Re: [PATCH 1/2] Create UV efi_call macros

On Thu, May 12, 2016 at 01:06:00PM +0100, Matt Fleming wrote: > (Adding author of arch_efi_call code) > > On Wed, 11 May, at 02:55:44PM, Alex Thorlton wrote: > > We need a slightly different macro than the standard efi_call_virt, > > since those macros all assume that th

Re: [PATCH 1/2] Create UV efi_call macros

On Thu, May 12, 2016 at 01:06:00PM +0100, Matt Fleming wrote: > (Adding author of arch_efi_call code) > > On Wed, 11 May, at 02:55:44PM, Alex Thorlton wrote: > > We need a slightly different macro than the standard efi_call_virt, > > since those macros all assume that th

Re: [GIT PULL] EFI fix

On Mon, May 16, 2016 at 03:23:51PM -0500, Alex Thorlton wrote: > Everything discussed above makes sense to me, and the patch looks sane. > I will apply and test it today and let you know how it works. I applied this to the latest -tip kernel and tested on both real hardware and in our sim

Re: [GIT PULL] EFI fix

On Mon, May 16, 2016 at 03:23:51PM -0500, Alex Thorlton wrote: > Everything discussed above makes sense to me, and the patch looks sane. > I will apply and test it today and let you know how it works. I applied this to the latest -tip kernel and tested on both real hardware and in our sim

Re: [GIT PULL] EFI fix

On Mon, May 16, 2016 at 01:05:45PM -0700, Linus Torvalds wrote: > On Mon, May 16, 2016 at 7:46 AM, Ingo Molnar wrote: > > > > Please pull the latest efi-urgent-for-linus git tree from: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > efi-urgent-for-linus

Re: [GIT PULL] EFI fix

On Mon, May 16, 2016 at 01:05:45PM -0700, Linus Torvalds wrote: > On Mon, May 16, 2016 at 7:46 AM, Ingo Molnar wrote: > > > > Please pull the latest efi-urgent-for-linus git tree from: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > efi-urgent-for-linus > > > >#

  1   2   3   4   5   6   >