From: Praneeth Bajjuri
Current logic is performing hard reset and causing the programmed
registers to be wiped out.
as per datasheet: https://www.ti.com/lit/ds/symlink/dp83867cr.pdf
8.6.26 Control Register (CTRL)
do SW_RESTART to perform a reset not including the registers and is
acceptable to
to protect it against
premature shutdown, mark it shared.
Signed-off-by: Jan Kiszka
Acked-by: Praneeth Bajjuri
---
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
b/arch/arm64/boot/dts/ti/k3-am65
Hi Reinette,
> -Original Message-
> From: Reinette Chatre
> Sent: Thursday, May 21, 2020 9:12 AM
> To: Prakhya, Sai Praneeth ;
> sh...@kernel.org; sk...@linuxfoundation.org; linux-kselft...@vger.kernel.org
> Cc: t...@linutronix.de; mi...@redhat.com; b...@alien8.de; Luck
On Tue, 2019-08-06 at 10:36 +0200, Michal Hocko wrote:
> On Mon 05-08-19 20:05:27, Sai Praneeth Prakhya wrote:
> > When a user process exits, the kernel cleans up the mm_struct of the user
> > process and during cleanup, check_mm() checks the page tables of the user
> > proces
ed-by: Vlastimil Babka
Acked-by: Dave Hansen
Suggested-by: Dave Hansen
Reviewed-by: Anshuman Khandual
Signed-off-by: Sai Praneeth Prakhya
---
Changes from V2 to V3:
--
1. Add comment that suggests to update resident_page_types[] if there are any
changes to exisiting page typ
On Tue, 2019-08-06 at 09:30 -0700, Dave Hansen wrote:
> On 8/5/19 8:05 PM, Sai Praneeth Prakhya wrote:
> > +static const char * const resident_page_types[NR_MM_COUNTERS] = {
> > + [MM_FILEPAGES] = "MM_FILEPAGES",
> > + [MM_ANONPAGES] = "
gt; >>
> >> Also, change print function (from printk(KERN_ALERT, ..) to
> >> pr_alert()) so that it matches the other print statement.
> >>
> >> Cc: Ingo Molnar
> >> Cc: Vlastimil Babka
> >> Cc: Peter Zijlstra
> >> Cc: Andrew Mort
ngo Molnar
> > Cc: Vlastimil Babka
> > Cc: Peter Zijlstra
> > Cc: Andrew Morton
> > Cc: Anshuman Khandual
> > Acked-by: Dave Hansen
> > Suggested-by: Dave Hansen
> > Signed-off-by: Sai Praneeth Prakhya
>
> Acked-by: Vlastimil Babka
>
>
On Mon, 2019-08-05 at 15:28 +0200, Vlastimil Babka wrote:
> On 8/2/19 8:46 AM, Prakhya, Sai Praneeth wrote:
> > > > > > +static const char * const resident_page_types[NR_MM_COUNTERS] = {
> > > > > > + "MM_FILEPAGES",
> > &
human Khandual
Acked-by: Dave Hansen
Suggested-by: Dave Hansen
Signed-off-by: Sai Praneeth Prakhya
---
Changes from V1 to V2:
--
1. Move struct definition from header file to fork.c file, so that it won't be
included in every compilation unit. As this struct is used
> >
> > Cc: Ingo Molnar
> > Cc: Peter Zijlstra
> > Cc: Andrew Morton
> > Suggested-by/Acked-by: Dave Hansen
>
> Though I am not sure, should the above be two separate lines instead ?
Sure! Will split them in V2.
>
> > Signed-off-by: Sai
> > > > +static const char * const resident_page_types[NR_MM_COUNTERS] = {
> > > > + "MM_FILEPAGES",
> > > > + "MM_ANONPAGES",
> > > > + "MM_SWAPENTS",
> > > > + "MM_SHMEMPAGES",
> > > > +};
> > >
> > > But please let's not put this in a header file. We're asking the
> > >
> > With patch:
> > ---
> > [ 69.815453] mm/pgtable-generic.c:29: bad p4d
> > 84653642(80025ca37467)
> > [ 69.815872] BUG: Bad rss-counter state mm:014a6c03
> > type:MM_FILEPAGES val:2
> > [ 69.815962] BUG: Bad rss-counter state mm:014a6c03
> > type:MM_AN
r Zijlstra
Cc: Andrew Morton
Suggested-by/Acked-by: Dave Hansen
Signed-off-by: Sai Praneeth Prakhya
---
include/linux/mm_types_task.h | 7 +++
kernel/fork.c | 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/linux/mm_types_task.h b/inc
; > - __map_region(md, efi_va);
> > > + if (__map_region(md, efi_va))
> > > + return -ENOMEM;
> > > +
> > > md->virt_addr = efi_va;
> > > + return 0;
> >
> > Same error return problem of leaving ->virt_addr u
Commit-ID: 8fe55212aacfce9b7718de7964b3a3096ec30919
Gitweb: https://git.kernel.org/tip/8fe55212aacfce9b7718de7964b3a3096ec30919
Author: Sai Praneeth Prakhya
AuthorDate: Sat, 2 Feb 2019 10:41:10 +0100
Committer: Ingo Molnar
CommitDate: Mon, 4 Feb 2019 08:19:22 +0100
x86/efi: Mark
> > Acked-by: Ard Biesheuvel
> >
> > with the sidenote that I won't be able to test this myself until
> > monday at the earliest.
>
> OK, so I have tested both efi=old_map and mixed mode before and after
> applying this patch, using QEMU/KVM with 64-bit and 32-bit builds of OVMF
> [respectively]
Commit-ID: 1debf0958fa27b7c469dbf22754929ec59a7c0e7
Gitweb: https://git.kernel.org/tip/1debf0958fa27b7c469dbf22754929ec59a7c0e7
Author: Sai Praneeth Prakhya
AuthorDate: Fri, 21 Dec 2018 18:22:34 -0800
Committer: Ingo Molnar
CommitDate: Sat, 22 Dec 2018 20:58:30 +0100
x86/efi: Don&#
>
> * Sai Praneeth Prakhya wrote:
>
> > Commit d5052a7130a6 ("x86/efi: Unmap EFI boot services code/data
> > regions from efi_pgd") forgets to take two EFI modes into
> > consideration namely EFI_OLD_MEMMAP and EFI_MIXED_MODE.
>
> So the commit s
ely EFI regions like EFI_CONVENTIONAL_MEMORY,
EFI_LOADER_, EFI_BOOT_SERVICES_ and
EFI_RUNTIME_CODE/DATA regions) is mapped into efi_pgd all the time to
facilitate EFI runtime calls access it's arguments in 1:1 mode. Hence,
don't unmap EFI boot services code/data regions when booted in mixed mode.
Signed-of
> > > For the short term, could we simply make your changes dependent on
> > > efi != old_map? That gives us some time to fix the old_map case properly.
> >
> > Yes, I think we could and it should work but I hesitated to propose it
> > because (as you already noted) it's a short term fix and not th
> > > > Hi Thomas and Ingo,
> > > >
> > > > I recently noticed that the below commits [1] and [2] are broken
> > > > when kernel command line argument "efi=old_map" is passed. Sorry!
> > > > I missed to test this condition prior to sending these patches to
> > > > mailing list.
> > > > I am workin
> > Hi Thomas and Ingo,
> >
> > I recently noticed that the below commits [1] and [2] are broken when
> > kernel command line argument "efi=old_map" is passed. Sorry! I missed
> > to test this condition prior to sending these patches to mailing list.
> > I am working on a fix and will send it to ma
> Commit-ID: 08cfb38f3ef49cfd1bba11a00401451606477d80
> Gitweb:
> https://git.kernel.org/tip/08cfb38f3ef49cfd1bba11a00401451606477d80
> Author: Sai Praneeth Prakhya
> AuthorDate: Thu, 29 Nov 2018 18:12:24 +0100
> Committer: Ingo Molnar
> CommitDate: Fri, 30 Nov 2018 09
Commit-ID: 47c33a095e1fae376d74b4160a0d73c1a4e73969
Gitweb: https://git.kernel.org/tip/47c33a095e1fae376d74b4160a0d73c1a4e73969
Author: Sai Praneeth Prakhya
AuthorDate: Thu, 29 Nov 2018 18:12:25 +0100
Committer: Ingo Molnar
CommitDate: Fri, 30 Nov 2018 09:10:31 +0100
x86/efi: Move
Commit-ID: 08cfb38f3ef49cfd1bba11a00401451606477d80
Gitweb: https://git.kernel.org/tip/08cfb38f3ef49cfd1bba11a00401451606477d80
Author: Sai Praneeth Prakhya
AuthorDate: Thu, 29 Nov 2018 18:12:24 +0100
Committer: Ingo Molnar
CommitDate: Fri, 30 Nov 2018 09:10:30 +0100
x86/efi: Unmap
Commit-ID: 7e0dabd3010d6041ee0a952c1146b2150a11f1be
Gitweb: https://git.kernel.org/tip/7e0dabd3010d6041ee0a952c1146b2150a11f1be
Author: Sai Praneeth Prakhya
AuthorDate: Thu, 29 Nov 2018 18:12:23 +0100
Committer: Ingo Molnar
CommitDate: Fri, 30 Nov 2018 09:10:30 +0100
x86/mm/pageattr
> > +int kernel_unmap_pages_in_pgd(pgd_t *pgd, unsigned long address,
> > + unsigned long numpages)
> > +{
> > + int retval;
> > +
> > + /*
> > +* The typical sequence for unmapping is to find a pte through
> > +* lookup_address_in_pgd() (ideally, it should never
> > For (Intel) Memory Bandwidth features like MBA and MBM, perf iMC
> > (Integrated Memory Controller) is used for validation. As a part of
> > test, we run a benchmark (eg: fill_buf) and get memory bandwidth
> > values from MBM and iMC and verify if the difference between both the
> reported valu
> > No, the selftest in this patch set will not replace intel-cmt-cat or
> > vice versa.
> >
> > The selftest in this patch set has a different purpose from intel-cmt-cat:
> > the selftest is a test tool which validates resctrl functionalities
> > while intel-cmt-cat is mainly a utility that provid
From: Sai Praneeth
There may exist some buggy UEFI firmware implementations that access efi
memory regions other than EFI_RUNTIME_SERVICES_ even after
the kernel has assumed control of the platform. This violates UEFI
specification. Hence, provide a efi specific page fault handler which
recovers
> On Mon, Sep 03, 2018 at 05:03:56AM +, Prakhya, Sai Praneeth wrote:
> > Hmm.. thought that __efi_init might be confusing with the normal
> > __init attribute
>
> How would that be confusing? It has "__efi" prepended?!
>
> All I'm saying is, i
Commit-ID: 706d51681d636a0c4a5ef53395ec3b803e45ed4d
Gitweb: https://git.kernel.org/tip/706d51681d636a0c4a5ef53395ec3b803e45ed4d
Author: Sai Praneeth
AuthorDate: Wed, 1 Aug 2018 11:42:25 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 3 Aug 2018 12:50:34 +0200
x86/speculation
From: Sai Praneeth
Future Intel processors will support "Enhanced IBRS" which is an "always
on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and never
disabled.
>From the specification [1]:
"With enhanced IBRS, the predicted targets of indirect branches
e
> > Yes, that makes sense.
> > But on the machine, I see IBRS bit set on all cores. As you said,
> > someone else might be writing the MSR. I will try to find that out and will
> update the patch accordingly.
> >
> > I initially suspected it to be __ssb_select_mitigation() as I have
> > "spec_store
> The feature strings are automatically generated from the define. The comment
> can be used to supress them by an empty "" string or to modify them by a
> "override" string at the beginning of the comment.
I overlooked "override" part. Sorry! about that.
It's clear now. Thanks for the explanation
> There is no reason not to use indentation and quotation marks in a changelog.
> Squeezing it into square brackets does not really improve readability.
>
> From the specification [1]:
>
> "With enhanced IBRS, the predicted targets of indirect branches executed
>cannot be controlled by sof
From: Sai Praneeth
Some future Intel processors may support "Enhanced IBRS" which is an
"always on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and
never disabled.
[With enhanced IBRS, the predicted targets of indirect branches executed
cannot be controlled by softwa
> > >> From: Sai Praneeth Some future
> > >> Intel processors may support "Enhanced IBRS" which is an "always
> > >> on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and never
> > >> disabled. According to specifi
From: Sai Praneeth
Some future Intel processors may support "Enhanced IBRS" which is an
"always on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and
never disabled. According to specification[1], this should simplify
software enabling and improve performance.
[Wit
> > diff --git a/arch/x86/platform/efi/quirks.c
> > b/arch/x86/platform/efi/quirks.c index 36c1f8b9f7e0..6af39dc40325
> > 100644
> > --- a/arch/x86/platform/efi/quirks.c
> > +++ b/arch/x86/platform/efi/quirks.c
> > @@ -105,12 +105,11 @@ early_param("efi_no_storage_paranoia",
> > setup_storage_paran
Commit-ID: f5dcc214aae29a68b37b2b4183f7171724e7b02d
Gitweb: https://git.kernel.org/tip/f5dcc214aae29a68b37b2b4183f7171724e7b02d
Author: Sai Praneeth
AuthorDate: Wed, 11 Jul 2018 11:40:37 +0200
Committer: Ingo Molnar
CommitDate: Mon, 16 Jul 2018 00:43:12 +0200
efi: Remove the
Commit-ID: 3eb420e70d879ce0e6bf752accf5cdedb0a59de8
Gitweb: https://git.kernel.org/tip/3eb420e70d879ce0e6bf752accf5cdedb0a59de8
Author: Sai Praneeth
AuthorDate: Wed, 11 Jul 2018 11:40:35 +0200
Committer: Ingo Molnar
CommitDate: Mon, 16 Jul 2018 00:43:12 +0200
efi: Use a work queue to
Commit-ID: 5a58bc1b1edc18a9edff606ec99e6f6b723975f4
Gitweb: https://git.kernel.org/tip/5a58bc1b1edc18a9edff606ec99e6f6b723975f4
Author: Sai Praneeth
AuthorDate: Wed, 11 Jul 2018 11:40:34 +0200
Committer: Ingo Molnar
CommitDate: Mon, 16 Jul 2018 00:43:12 +0200
efi/x86: Use non-blocking
From: Sai Praneeth
efi_memmap_install(), unmaps the existing memory map and installs a new
memory map but doesn't free the memory allocated to the existing
memory map. Fortunately, the details about the existing memory map (like
the physical address, number of entries and type of memory
From: Sai Praneeth
Presently, when a user process requests the kernel to execute any
efi_runtime_service(), kernel switches the page directory (%cr3) from
swapper_pgd to efi_pgd. Other subsystems in the kernel aren't aware of
this switch and they might think, user space is still valid (i.e
From: Sai Praneeth
Presently, efi_delete_dummy_variable() uses set_variable() which might
block and hence kernel prints stack trace with a warning "bad:
scheduling from the idle thread!". So, make efi_delete_dummy_variable()
use set_variable_nonblocking(), which, as the name sugges
From: Sai Praneeth
Problem statement:
--
Presently, efi_runtime_services() silently switch %cr3 from swapper_pgd
to efi_pgd. As a consequence, kernel code that runs in efi_pgd (e.g.,
perf code via an NMI) will have incorrect user space mappings[1]. This
could lead to otherwise
From: Sai Praneeth
When a process requests the kernel to execute any efi_runtime_service(),
the requested efi_runtime_service (represented as an identifier) and its
arguments are packed into a struct named efi_runtime_work and queued
onto work queue named efi_rts_wq. The caller then waits until
> > Another follow on question is, does every firmware support both
> > blocking and non-blocking variants (specially legacy EFI firmware)? I
> > am worried about this because, presently efi_delete_dummy_variable()
> > uses set_variable() and
> > query_variable_info() but if I change efi_delete_dum
> > One more question again, if we are sure that non-blocking variants
> > will _always_ be called in atomic context, then, we got it covered.
> > Because, in
> > set_variable() and query_variable_info() (both blocking and
> > non-blocking) we check for in_atomic() and if so, we don't use efi_rts_w
> > Assume some user requested to execute some non-blocking variant of
> > efi_rts and the kernel hasn't called efi_call_virt() yet, but was
> > scheduled out. IOW, even though user requests for non-blocking efi call, we
> might still block. Am I right?
> >
>
> No, that is the whole point. These f
> > Changes from V3 to V4:
> > --
> > 1. As suggested by Peter, use completions instead of flush_work() as the
> > former is cheaper
> > 2. Call efi_delete_dummy_variable() from efisubsys_init(). Sorry! Ard,
> > wasn't able to find a better alternative to keep this change lo
From: Sai Praneeth
Invoking efi_runtime_services() through efi_rts_wq (efi runtime
services workqueue) means all accesses to efi_runtime_services() should
be done after efi_rts_wq has been created. efi_delete_dummy_variable()
calls set_variable(), hence efi_delete_dummy_variable() should be
From: Sai Praneeth
Problem statement:
--
Presently, efi_runtime_services() silently switch %cr3 from swapper_pgd
to efi_pgd. As a consequence, kernel code that runs in efi_pgd (e.g.,
perf code via an NMI) will have incorrect user space mappings[1]. This
could lead to otherwise
From: Sai Praneeth
Presently, when a user process requests the kernel to execute any
efi_runtime_service(), kernel switches the page directory (%cr3) from
swapper_pgd to efi_pgd. Other subsystems in the kernel aren't aware of
this switch and they might think, user space is still valid (i.e
From: Sai Praneeth
When a process requests the kernel to execute any efi_runtime_service(),
the requested efi_runtime_service (represented as an identifier) and its
arguments are packed into a struct named efi_runtime_work and queued
onto work queue named efi_rts_wq. The caller then waits until
> On Mon, May 21, 2018 at 08:13:03PM -0700, Sai Praneeth Prakhya wrote:
> > + /* \
> > +* queue_work() returns 0 if work was already on queue, \
> > +* _ideally_ thi
From: Sai Praneeth
Create a workqueue named efi_rts_wq (efi runtime services workqueue), so
that all efi_runtime_services() are executed in kthread context.
Invoking efi_runtime_services() through efi_rts_wq means all accesses to
efi_runtime_services() should be done after efi_rts_wq has been
From: Sai Praneeth
When a process requests the kernel to execute any efi_runtime_service(),
the requested efi_runtime_service (represented as an identifier) and its
arguments are packed into a struct named efi_runtime_work and queued
onto work queue named efi_rts_wq. The caller then waits until
From: Sai Praneeth
Presently, when a user process requests the kernel to execute any
efi_runtime_service(), kernel switches the page directory (%cr3) from
swapper_pgd to efi_pgd. Other subsystems in the kernel aren't aware of
this switch and they might think, user space is still valid (i.e
From: Sai Praneeth
Problem statement:
--
Presently, efi_runtime_services() silently switch %cr3 from swapper_pgd
to efi_pgd. As a consequence, kernel code that runs in efi_pgd (e.g.,
perf code via an NMI) will have incorrect user space mappings[1]. This
could lead to otherwise
Commit-ID: 162ee5a8ab49be40d253f90e94aef712470a3a24
Gitweb: https://git.kernel.org/tip/162ee5a8ab49be40d253f90e94aef712470a3a24
Author: Sai Praneeth
AuthorDate: Wed, 4 Apr 2018 12:34:19 -0700
Committer: Ingo Molnar
CommitDate: Thu, 5 Apr 2018 01:27:49 +0200
x86/mm: Fix bogus warning
From: Sai Praneeth
When the platform supports PCID and if CONFIG_DEBUG_VM is enabled,
build_cr3_noflush() (called via switch_mm()) does a sanity check to see
if X86_FEATURE_PCID is set. Presently, build_cr3_noflush() uses
"this_cpu_has(X86_FEATURE_PCID)" to perform the check but th
Commit-ID: 7e904a91bf6049071ef9d605a52f863ae774081d
Gitweb: https://git.kernel.org/tip/7e904a91bf6049071ef9d605a52f863ae774081d
Author: Sai Praneeth
AuthorDate: Mon, 12 Mar 2018 08:44:56 +
Committer: Ingo Molnar
CommitDate: Mon, 12 Mar 2018 10:05:01 +0100
efi: Use efi_mm in x86 as
> > That's true! AFAIK, we don't have any issues handling NMI while in efi_pgd.
> > We might have issues only when, we are already in efi_pgd, NMI comes
> > along
>
> Can you trigger this? Or is it something hypothetical?
>
AFAIK, it's hypothetical. I did try to trigger the issue, but failed [1]
> > diff --git a/include/linux/efi.h b/include/linux/efi.h index
> > f5083aa72eae..f1b7d68ac460 100644
> > --- a/include/linux/efi.h
> > +++ b/include/linux/efi.h
> > @@ -966,6 +966,8 @@ extern struct efi {
> > unsigned long flags;
> > } efi;
> >
> > +extern struct mm_struct efi_mm;
> > +
> >
> > Another warning by checkpatch is "use of in_atomic() in drivers code"
>
> I'm assuming it warns because you're touching files in drivers/ but the efi
> fun is
> not really a driver...
True! That makes sense :)
>
> But looking at patch 3, that thing looks like a real mess. Some of the thing
/*
> >> > +* Since we process only one efi_runtime_service() at a time, an
> >> > +* ordered workqueue (which creates only one execution context)
> >> > +* should suffice all our needs.
> >> > +*/
> >> > + efi_rts_wq = alloc_ordered_workqueue("efi_rts_workqueue
> > void __init efi_enter_virtual_mode(void) diff --git
> > a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index
> > cd42f66a7c85..838b8efe639c 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -328,6 +328,12 @@ static int __init efisubsys_init(void
+Cc Miguel Ojeda
> > > +({
> > > \
> > > + struct efi_runtime_work efi_rts_work; \
> > > + \
> > > + INIT_WORK_ONSTACK(&efi_rts_work.work
> > +({ \
> > + struct efi_runtime_work efi_rts_work; \
> > + \
> > + INIT_WORK_ONSTACK(&efi_rts_work.work, efi_call_rts);\
> >
> >> > pstore writes could potentially be invoked in interrupt context and
> >> > it uses set_variable<>() and query_variable_info<>() to store logs.
> >> > If we invoke efi_runtime_services() through efi_rts_wq while in
> >> > atomic() kernel issues a warning ("scheduling wile in atomic") and
> >>
> > +struct workqueue_struct *efi_rts_wq;
> > +
> > static bool disable_runtime;
> > static int __init setup_noefi(char *arg) { @@ -329,6 +331,19 @@
> > static int __init efisubsys_init(void)
> > return 0;
> >
> > /*
> > +* Since we process only one efi_runtime_se
05, 2018 at 03:23:10PM -0800, Sai Praneeth Prakhya wrote:
> > From: Sai Praneeth
> >
> > Presently, efi_runtime_services() are executed by firmware in process
> > context. To execute efi_runtime_service(), kernel switches the page
> > directory from swapper_pg
-0800, Sai Praneeth Prakhya wrote:
> > @@ -329,6 +331,19 @@ static int __init efisubsys_init(void)
> > return 0;
> >
> > /*
> > +* Since we process only one efi_runtime_service() at a time, an
> > +* ordered workqueue (whic
> > Presently, efi_runtime_services() are executed by firmware in process
> > context. To execute efi_runtime_service(), kernel switches the page
> > directory from swapper_pgd to efi_pgd. However, efi_pgd doesn't have
> > any user space mappings. A potential issue could be, for instance, an
> > NM
From: Sai Praneeth
Invoking efi_runtime_services() through efi_workqueue means all accesses
to efi_runtime_services() should be done after efi_rts_wq has been
created. efi_delete_dummy_variable() calls set_variable(), hence
efi_delete_dummy_variable() should be called after efi_rts_wq has been
From: Sai Praneeth
This patch set is an outcome of the discussion at
https://lkml.org/lkml/2017/8/21/607
Presently, efi_runtime_services() are executed by firmware in process
context. To execute efi_runtime_service(), kernel switches the page
directory from swapper_pgd to efi_pgd. However
From: Sai Praneeth
When a process requests the kernel to execute any efi_runtime_service(),
the requested efi_runtime_service (represented as an identifier) and its
arguments are packed into a struct named efi_runtime_work and queued
onto work queue named efi_rts_wq. The caller then waits until
From: Sai Praneeth
Presently, efi_runtime_services() are executed by firmware in process
context. To execute efi_runtime_service(), kernel switches the page
directory from swapper_pgd to efi_pgd. However, efi_pgd doesn't have any
user space mappings. A potential issue could be, for instanc
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index ac5db5f8dbbf..4714b305ca90 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -76,6 +76,8 @@ static unsigned long *efi_tables[] = {
> > &efi.mem_attr_table,
> > };
> >
>
From: Sai Praneeth
Invoking efi_runtime_services() through efi_workqueue means all accesses
to efi_runtime_services() should be done after efi_rts_wq has been
created. efi_delete_dummy_variable() calls set_variable(), hence
efi_delete_dummy_variable() should be called after efi_rts_wq has been
From: Sai Praneeth
Presently, efi_runtime_services() are executed by firmware in process
context. To execute efi_runtime_service(), kernel switches the page
directory from swapper_pgd to efi_pgd. However, efi_pgd doesn't have any
user space mappings. A potential issue could be, for instanc
From: Sai Praneeth
When a process requests the kernel to execute any efi_runtime_service(),
the requested efi_runtime_service (represented as an identifier) and its
arguments are packed into a struct named efi_runtime_work and queued
onto work queue named efi_rts_wq. The caller then waits until
From: Sai Praneeth
This patch set is an outcome of the discussion at
https://lkml.org/lkml/2017/8/21/607
Presently, efi_runtime_services() are executed by firmware in process
context. To execute efi_runtime_service(), kernel switches the page
directory from swapper_pgd to efi_pgd. However
From: Sai Praneeth
Use helper function (efi_switch_mm()) to switch to/from efi_mm. We
switch to efi_mm before calling
1. efi_set_virtual_address_map() and
2. Invoking any efi_runtime_service()
Likewise, we need to switch back to previous mm (mm context stolen by
efi_mm) after the above calls
From: Sai Praneeth
Since the previous patch added support for efi_mm, let's handle efi_pgd
through efi_mm and remove global variable efi_pgd.
Signed-off-by: Sai Praneeth Prakhya
Cc: Lee, Chun-Yi
Cc: Borislav Petkov
Cc: Tony Luck
Cc: Andy Lutomirski
Cc: Michael S. Tsirkin
Cc: Bh
From: Sai Praneeth
Presently, only ARM uses mm_struct to manage efi page tables and efi
runtime region mappings. As this is the preferred approach, let's make
this data structure common across architectures. Specially, for x86,
using this data structure improves code maintainabilit
From: Sai Praneeth
Presently, in x86, to invoke any efi function like
efi_set_virtual_address_map() or any efi_runtime_service() the code path
typically involves read_cr3() (save previous pgd), write_cr3()
(write efi_pgd) and calling efi function. Likewise after returning from
efi function the
> > Changes in V3:
> > 1. When CPUMASK_OFFSTACK is enabled, switch_mm_irqs_off() sets cpumask
> > by calling cpumask_set_cpu(). This panics kernel as efi_mm is not
> > initialized, therefore initialize efi_mm in efi_alloc_page_tables().
>
> Thanks for the v3.
>
> I confirmed that the issue I saw
From: Sai Praneeth
Since the previous patch added support for efi_mm, let's handle efi_pgd
through efi_mm and remove global variable efi_pgd.
Signed-off-by: Sai Praneeth Prakhya
Cc: Lee, Chun-Yi
Cc: Borislav Petkov
Cc: Tony Luck
Cc: Andy Lutomirski
Cc: Michael S. Tsirkin
Cc: Bh
From: Sai Praneeth
Use helper function (efi_switch_mm()) to switch to/from efi_mm. We
switch to efi_mm before calling
1. efi_set_virtual_address_map() and
2. Invoking any efi_runtime_service()
Likewise, we need to switch back to previous mm (mm context stolen by
efi_mm) after the above calls
From: Sai Praneeth
Presently, only ARM uses mm_struct to manage efi page tables and efi
runtime region mappings. As this is the preferred approach, let's make
this data structure common across architectures. Specially, for x86,
using this data structure improves code maintainabilit
From: Sai Praneeth
Presently, in x86, to invoke any efi function like
efi_set_virtual_address_map() or any efi_runtime_service() the code path
typically involves read_cr3() (save previous pgd), write_cr3()
(write efi_pgd) and calling efi function. Likewise after returning from
efi function the
>
>
> Hi Andy,
>
> I have booted Linus's tree (8fac2f96ab86b0e14ec4e42851e21e9b518bdc55) on
> Skylake server and noticed that it reboots automatically.
>
> When I booted the same kernel with command line arg "nopcid" it works
> fine. Please find below a snippet of dmesg. Please let me know if y
> From: Andy Lutomirski
> Date: Thu, Jun 29, 2017 at 8:53 AM
> Subject: [PATCH v4 00/10] PCID and improved laziness
> To: x...@kernel.org
> Cc: linux-kernel@vger.kernel.org, Borislav Petkov ,
> Linus Torvalds , Andrew Morton
> , Mel Gorman ,
> "linux...@kvack.org" , Nadav Amit
> , Rik van Riel , D
> So, in summary it seems that the primary kernel boot _fails_ with your
> v2 patchset on the real hardware for me irrespective of whether I use Matt's
> tree or Linus's tree:
>
> a) I would suggest that you perform some more checks on real hardware as
> qemu boot tests sometimes do not expose the
> -Original Message-
> From: Sai Praneeth Prakhya [mailto:sai.praneeth.prak...@intel.com]
> Sent: Tuesday, September 5, 2017 7:43 PM
> To: Bhupesh Sharma
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Matt Fleming
> ; Ard Biesheuvel ;
> j...@suse
On Tue, 2017-09-05 at 19:21 -0700, Sai Praneeth Prakhya wrote:
> > I get a similar crash on Qemu with linus's master branch and the V2
> > applied on top of it. Here are the details of my test environment:
> >
> > 1. I use the OVMF (EDK2) EFI firmware to launch the
1 - 100 of 144 matches
Mail list logo
