I forgot to mark this series as v2 when generating the patches.
Sorry for the confusion.
--
Thiago Jung Bauermann
IBM Linux Technology Center
Secure Memory Encryption is an x86-specific feature, so it shouldn't appear
in generic kernel code.
In DMA mapping code, Christoph Hellwig mentioned that "There is no reason
why we should have a special debug printk just for one specific reason why
there is a requirement for a large DMA mask.",
Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
appear in generic kernel code because it forces non-x86 architectures to
define the sev_active() function, which doesn't make a lot of sense.
To solve this problem, add an x86 elfcorehdr_read() function to override
the
powerpc is also going to use this feature, so put it in a generic location.
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Thomas Gleixner
---
arch/Kconfig | 3 +++
arch/s390/Kconfig | 3 ---
arch/x86/Kconfig | 4 +---
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git
Hello,
This version mostly changes patch 2/3, removing dma_check_mask() from
kernel/dma/mapping.c as suggested by Christoph Hellwig, and also adapting
s390's . There's also a small change in patch 1/3 as
mentioned in the changelog below.
Patch 3/3 may or may not need to change s390 code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Linus,
Please pull powerpc updates for 5.3.
A bit of a small batch for us, just due to me not getting the time to review
things. Only one conflict that I'm aware of, in our pgtable.h, resolution is
simply to take both sides.
cheers
The
Suraj Jitindar Singh writes:
> The performance monitoring unit (PMU) registers are saved on guest exit
> when the guest has set the pmcregs_in_use flag in its lppaca, if it
> exists, or unconditionally if it doesn't. If a nested guest is being
> run then the hypervisor doesn't, and in most cases
The KBUILD_ARFLAGS addition in arch/powerpc/Makefile has never worked
in a useful way because it is always overridden by the following code
in the top Makefile:
# use the deterministic mode of AR if available
KBUILD_ARFLAGS := $(call ar-option,D)
The code in the top Makefile was added in
On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote:
> On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote:
>
> > if (flags & LOOKUP_BENEATH) {
> > nd->root = nd->path;
> > if (!(flags & LOOKUP_RCU))
> > path_get(>root);
> > else
On Fri, 2019-07-12 at 19:37 +1000, Alexey Kardashevskiy wrote:
>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/irq.c#n614
>
> If so, then in order to do EOI, I'll need the desc which is gone, or
> I am missing the point?
All you need is drop the
[ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]
Hello Christoph,
Christoph Hellwig writes:
> Honestly I think this code should go away without any replacement.
> There is no reason why we should have a special debug printk just
> for one specific reason why there is a
Hello Thomas,
Thanks for quickly reviewing the patches.
Thomas Gleixner writes:
> On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
>
>> powerpc and s390 are going to use this feature as well, so put it in a
>> generic location.
>>
>> Signed-off-by: Thiago Jung Bauermann
>
> Reviewed-by:
[ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]
Hello Halil,
Thanks for the quick review.
Halil Pasic writes:
> On Fri, 12 Jul 2019 02:36:31 -0300
> Thiago Jung Bauermann wrote:
>
>> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
>>
On 7/11/19 9:57 PM, Nicholas Piggin wrote:
> Claudio Carvalho's on June 29, 2019 6:08 am:
>> From: Sukadev Bhattiprolu
>>
>> The ultravisor processor mode is introduced in POWER platforms that
>> supports the Protected Execution Facility (PEF). Ultravisor is higher
>> privileged than hypervisor
On Fri, 12 Jul 2019 10:20:07 +0800
Alex Shi wrote:
> There are many different archs in Documentation/ dir, it's better to
> move them together in 'Documentation/arch' which follows from kernel source.
So this seems certain to collide badly with Mauro's RST-conversion monster
patch set.
More to
On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
> diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
> index b310a9c18113..f2e399fb626b 100644
> --- a/include/linux/mem_encrypt.h
> +++ b/include/linux/mem_encrypt.h
> @@ -21,23 +21,11 @@
>
> #else/*
On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
> powerpc and s390 are going to use this feature as well, so put it in a
> generic location.
>
> Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Thomas Gleixner
https://bugzilla.kernel.org/show_bug.cgi?id=204125
--- Comment #8 from Daniel Kolesa (li...@octaforge.org) ---
Using this patch on my machines now:
https://gist.github.com/q66/625cbec5d7317829a302773f89533b51 seems to work well
--
You are receiving this mail because:
You are watching the
On Fri, Jul 12, 2019 at 08:01:07AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 11, 2019 at 04:45:41PM -0400, Joel Fernandes (Google) wrote:
> > The rcu_dereference_raw_notrace() API name is confusing.
> > It is equivalent to rcu_dereference_raw() except that it also does
> > sparse pointer
On 2019-07-12, Al Viro wrote:
> On Sun, Jul 07, 2019 at 12:57:27AM +1000, Aleksa Sarai wrote:
> > Patch changelog:
> > v9:
> > * Replace resolveat(2) with openat2(2). [Linus]
> > * Output a warning to dmesg if may_open_magiclink() is violated.
> > * Add an openat2(O_CREAT) testcase.
Ping.
On Fri, 2019-06-28 at 10:03 -0400, Qian Cai wrote:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warnings,
>
>
Ping.
On Wed, 2019-05-22 at 12:09 -0400, Qian Cai wrote:
> The commit b575c731fe58 ("powerpc/powernv/npu: Add set/unset window
> helpers") called pnv_npu_set_window() in a void function
> pnv_npu_dma_set_32(), but the return code from pnv_npu_set_window() has
> no use there as all the error
On Fri, Jul 12, 2019 at 07:45:05PM +1000, Alexey Kardashevskiy wrote:
> This is an attempt to allow DMA masks between 32..59 which are not large
> enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
> on the max order, up to 40 is usually available.
Can you elaborate what you
> -extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
> - int nid);
> +extern struct iommu_table *iommu_init_table_res(struct iommu_table *tbl,
> + int nid, unsigned long res_start, unsigned long res_end);
> +#define
> This skips the 32bit DMA setup check if the bypass is can be selected.
That sentence does not parse. I think you need to dop the "can be"
based on the actual patch.
On Sun, Jul 07, 2019 at 12:57:27AM +1000, Aleksa Sarai wrote:
> Patch changelog:
> v9:
> * Replace resolveat(2) with openat2(2). [Linus]
> * Output a warning to dmesg if may_open_magiclink() is violated.
> * Add an openat2(O_CREAT) testcase.
One general note for the future, BTW: for
On Fri, Jul 12, 2019 at 04:51:53PM +0200, Halil Pasic wrote:
> Thank you very much! I will have another look, but it seems to me,
> without further measures taken, this would break protected virtualization
> support on s390. The effect of the che for s390 is that
> force_dma_unencrypted() will
On Thu, Jul 11, 2019 at 04:45:41PM -0400, Joel Fernandes (Google) wrote:
> The rcu_dereference_raw_notrace() API name is confusing.
> It is equivalent to rcu_dereference_raw() except that it also does
> sparse pointer checking.
>
> There are only a few users of rcu_dereference_raw_notrace(). This
On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote:
> if (flags & LOOKUP_BENEATH) {
> nd->root = nd->path;
> if (!(flags & LOOKUP_RCU))
> path_get(>root);
> else
> nd->root_seq = nd->seq;
BTW, this
On Fri 12-07-19 15:37:30, Will Deacon wrote:
> Hi all,
>
> On Fri, Jul 12, 2019 at 02:12:23PM +0200, Michal Hocko wrote:
> > On Fri 12-07-19 10:56:47, Hoan Tran OS wrote:
> > [...]
> > > It would be good if we can enable it by-default. Otherwise, let arch
> > > enables it by them-self. Do you
Hi all,
On Fri, Jul 12, 2019 at 02:12:23PM +0200, Michal Hocko wrote:
> On Fri 12-07-19 10:56:47, Hoan Tran OS wrote:
> [...]
> > It would be good if we can enable it by-default. Otherwise, let arch
> > enables it by them-self. Do you have any suggestions?
>
> I can hardly make any suggestions
On Fri, Jul 12, 2019 at 03:09:12PM +0200, Halil Pasic wrote:
> This is the implementation for the guys that don't
> have ARCH_HAS_MEM_ENCRYPT.
>
> Means sev_active() may not be used in such code after this
> patch. What about
>
> static inline bool force_dma_unencrypted(void)
> {
>
On Fri, Jul 12, 2019 at 01:55:52PM +0100, Al Viro wrote:
> On Fri, Jul 12, 2019 at 01:39:24PM +0100, Al Viro wrote:
> > On Fri, Jul 12, 2019 at 08:57:45PM +1000, Aleksa Sarai wrote:
> >
> > > > > @@ -2350,9 +2400,11 @@ static const char *path_init(struct nameidata
> > > > > *nd, unsigned flags)
On Fri, Jul 12, 2019 at 10:20:17PM +1000, Aleksa Sarai wrote:
> On 2019-07-12, Al Viro wrote:
> > On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int
> > > dfd, struct filename *name)
> > > p->stack =
Suraj Jitindar Singh writes:
> The virtual real mode addressing (VRMA) mechanism is used when a
> partition is using HPT (Hash Page Table) translation and performs
> real mode accesses (MSR[IR|DR] = 0) in non-hypervisor mode. In this
> mode effective address bits 0:23 are treated as zero (i.e.
On Fri, Jul 12, 2019 at 01:39:24PM +0100, Al Viro wrote:
> On Fri, Jul 12, 2019 at 08:57:45PM +1000, Aleksa Sarai wrote:
>
> > > > @@ -2350,9 +2400,11 @@ static const char *path_init(struct nameidata
> > > > *nd, unsigned flags)
> > > > s = ERR_PTR(error);
> > > >
On Fri, Jul 12, 2019 at 08:57:45PM +1000, Aleksa Sarai wrote:
> > > @@ -2350,9 +2400,11 @@ static const char *path_init(struct nameidata *nd,
> > > unsigned flags)
> > > s = ERR_PTR(error);
> > > return s;
> > > }
> > > - error = dirfd_path_init(nd);
> > > - if
Le 12/07/2019 à 14:22, Michael Ellerman a écrit :
Christophe Leroy writes:
Le 12/07/2019 à 08:25, Michael Ellerman a écrit :
"Aneesh Kumar K.V" writes:
...
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 11caa0291254..b181d6860f28 100644
---
Christophe Leroy writes:
> Le 12/07/2019 à 08:25, Michael Ellerman a écrit :
>> "Aneesh Kumar K.V" writes:
...
>>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>>> index 11caa0291254..b181d6860f28 100644
>>> --- a/arch/powerpc/kernel/traps.c
>>> +++
On 2019-07-12, Al Viro wrote:
> On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int
> > dfd, struct filename *name)
> > p->stack = p->internal;
> > p->dfd = dfd;
> > p->name = name;
> > -
On 2019-07-12, Aleksa Sarai wrote:
> On 2019-07-12, Al Viro wrote:
> > On Sun, Jul 07, 2019 at 12:57:31AM +1000, Aleksa Sarai wrote:
> > > Previously, path_init's handling of *at(dfd, ...) was only done once,
> > > but with LOOKUP_BENEATH (and LOOKUP_IN_ROOT) we have to parse the
> > > initial
On Fri 12-07-19 10:56:47, Hoan Tran OS wrote:
[...]
> It would be good if we can enable it by-default. Otherwise, let arch
> enables it by them-self. Do you have any suggestions?
I can hardly make any suggestions when it is not really clear _why_ you
want to remove this config option in the
On 2019-07-12, Al Viro wrote:
> On Sun, Jul 07, 2019 at 12:57:31AM +1000, Aleksa Sarai wrote:
> > Previously, path_init's handling of *at(dfd, ...) was only done once,
> > but with LOOKUP_BENEATH (and LOOKUP_IN_ROOT) we have to parse the
> > initial nd->path at different times (before or after
On 2019-07-12, Al Viro wrote:
> On Sun, Jul 07, 2019 at 12:57:32AM +1000, Aleksa Sarai wrote:
> > @@ -1442,8 +1464,11 @@ static int follow_dotdot_rcu(struct nameidata *nd)
> > struct inode *inode = nd->inode;
> >
> > while (1) {
> > - if (path_equal(>path, >root))
> > +
Hi,
On 7/12/19 2:02 PM, Michal Hocko wrote:
> On Thu 11-07-19 23:25:44, Hoan Tran OS wrote:
>> In NUMA layout which nodes have memory ranges that span across other nodes,
>> the mm driver can detect the memory node id incorrectly.
>>
>> For example, with layout below
>> Node 0 address:
On 07/12/2019 12:37 PM, Michael Ellerman wrote:
> Anshuman Khandual writes:
>> On 07/03/2019 04:36 AM, Andrew Morton wrote:
>>> On Fri, 28 Jun 2019 10:50:31 +0530 Anshuman Khandual
>>> wrote:
>>>
Finishing up what the commit c2febafc67734a ("mm: convert generic code to
5-level
We allocate only the first level of multilevel TCE tables for KVM
already (alloc_userspace_copy==true), and the rest is allocated on demand.
This is not enabled though for bare metal.
This removes the KVM limitation (implicit, via the alloc_userspace_copy
parameter) and always allocates just the
POWER8 and newer support a bypass mode which maps all host memory to
PCI buses so an IOMMU table is not always required. However if we fail to
create such a table, the DMA setup fails and the kernel does not boot.
This skips the 32bit DMA setup check if the bypass is can be selected.
At the moment we create a small window only for 32bit devices, the window
maps 0..2GB of the PCI space only. For other devices we either use
a sketchy bypass or hardware bypass but the former can only work if
the amount of RAM is no bigger than the device's DMA mask and the latter
requires devices
pnv_tce() returns a pointer to a TCE entry and originally a TCE table
would be pre-allocated. For the default case of 2GB window the table
needs only a single level and that is fine. However if more levels are
requested, it is possible to get a race when 2 threads want a pointer
to a TCE entry
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
on the max order, up to 40 is usually available.
Changelogs are in the patches.
This is based on sha1
a2b6f26c264e Christophe Leroy "powerpc/module64:
On 12/07/2019 18:29, Benjamin Herrenschmidt wrote:
On Fri, 2019-07-12 at 18:20 +1000, Alexey Kardashevskiy wrote:
diff --git a/arch/powerpc/sysdev/xive/common.c
b/arch/powerpc/sysdev/xive/common.c
index 082c7e1c20f0..65742e280337 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++
Hi all,
On Fri, 12 Jul 2019 17:07:48 +1000 Michael Ellerman wrote:
>
> The return value of arch_ioremap_p4d_supported() is stored in the
> variable ioremap_p4d_capable which is then returned by
> ioremap_p4d_enabled().
>
> That is used by ioremap_try_huge_p4d() called from ioremap_p4d_range()
>
On Fri, 2019-07-12 at 18:20 +1000, Alexey Kardashevskiy wrote:
>
> diff --git a/arch/powerpc/sysdev/xive/common.c
> b/arch/powerpc/sysdev/xive/common.c
> index 082c7e1c20f0..65742e280337 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -148,8
There is a race between releasing an irq on one cpu and fetching it
from XIVE on another cpu as there does not seem to be any locking between
these, probably because xive_irq_chip::irq_shutdown() is supposed to
remove the irq from all queues in the system which it does not do.
As a result, when
Honestly I think this code should go away without any replacement.
There is no reason why we should have a special debug printk just
for one specific reason why there is a requirement for a large DMA
mask.
Anshuman Khandual writes:
> On 07/03/2019 04:36 AM, Andrew Morton wrote:
>> On Fri, 28 Jun 2019 10:50:31 +0530 Anshuman Khandual
>> wrote:
>>
>>> Finishing up what the commit c2febafc67734a ("mm: convert generic code to
>>> 5-level paging") started out while levelling up P4D huge mapping
The disable callback can be used to compute timeout for other states
whenever a state is enabled or disabled. We store the computed timeout
in "timeout" defined in cpuidle state strucure. So, we compute timeout
only when some state is enabled or disabled and not every time in the
fast idle path.
To force wakeup a cpu, we need to compute the timeout in the fast idle
path as a state may be enabled or disabled but there did not exist a
feedback to driver when a state is enabled or disabled.
This patch adds a callback whenever a state_usage records a store for
disable attribute.
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect, there are cases
where the governor predicts a shallow idle state, hoping that the CPU will
be
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect, there are cases
where the governor predicts a shallow idle state, hoping that the CPU will
be
On Thu 11-07-19 23:25:44, Hoan Tran OS wrote:
> In NUMA layout which nodes have memory ranges that span across other nodes,
> the mm driver can detect the memory node id incorrectly.
>
> For example, with layout below
> Node 0 address:
> Node 1 address:
>
Christophe Leroy writes:
> Le 08/07/2019 à 02:56, Michael Ellerman a écrit :
>> Christophe Leroy writes:
>>> To increase readability/maintainability, replace hard coded
>>> instructions values by symbolic names.
>>>
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> v3: fixed warning by adding ()
Le 12/07/2019 à 08:25, Michael Ellerman a écrit :
"Aneesh Kumar K.V" writes:
Avoids confusion when printing Oops message like below
Faulting instruction address: 0xc008bdb4
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048
On Fri, Jul 12, 2019 at 05:14:54AM +0100, Al Viro wrote:
> That's not quite guaranteed (it is possible to bind a symlink on top
> of a regular file, and you will get LOOKUP_JUMPED on the entry into
> trailing_symlink() when looking the result up). Moreover, why bother
> with LOOKUP_JUMPED here?
Nicholas Piggin writes:
> Claudio Carvalho's on June 29, 2019 6:08 am:
>> From: Sukadev Bhattiprolu
>>
>> The ultravisor processor mode is introduced in POWER platforms that
>> supports the Protected Execution Facility (PEF). Ultravisor is higher
>> privileged than hypervisor mode.
>>
>> In
"Aneesh Kumar K.V" writes:
> Avoids confusion when printing Oops message like below
>
> Faulting instruction address: 0xc008bdb4
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>
> This was because we never clear the
67 matches
Mail list logo
