On 11/12/2019 12:43, Michael Roth wrote:
> Quoting Ram Pai (2019-12-06 19:12:39)
>> Commit edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on
>> secure guests")
>> disabled dma_iommu_ops path, for secure VMs. Disabling dma_iommu_ops
>> path for secure VMs, helped
On Wed, 11 Dec 2019 12:43:37 +1100
Daniel Axtens wrote:
> If a process page-faults trying to write beyond the end of its
> stack, we attempt to grow the stack.
>
> However, if the kernel attempts to write beyond the end of a
> process's stack, it takes a bad fault. This can occur when the
>
On Tue 10-12-19 16:52:31, Logan Gunthorpe wrote:
[...]
> In my opinion, having a coder and reviewer see PAGE_KERNEL and ask if
> that makes sense is a benefit. Having it hidden because we don't want
> people to think about it is worse, harder to understand and results in
> bugs that are more
> Fixes: 14cf11af6cf6 ("powerpc: Merge enough to start building in
> arch/powerpc.")
Wow, that's pretty ancient! I'm also not sure it's right - in that same
patch, arch/ppc64/mm/fault.c contains:
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 213)
if (address + 2048
On 11/12/2019 02:35, Ram Pai wrote:
> On Tue, Dec 10, 2019 at 04:32:10PM +1100, Alexey Kardashevskiy wrote:
>>
>>
>> On 10/12/2019 16:12, Ram Pai wrote:
>>> On Tue, Dec 10, 2019 at 02:07:36PM +1100, Alexey Kardashevskiy wrote:
On 07/12/2019 12:12, Ram Pai wrote:
>
Provide facilities to decode machine checks into human readable
strings, with only sufficient information required to deal with
them sanely.
The old machine check stuff was over engineered. The philosophy
here is that OPAL should correct anything it possibly can, what
it can't handle but the OS
I have an iMac iSight with a 2.1 GHz PowerPC 970fx (G5) processor, that
boots fine with the latest ppc64 kernel.
Romain Dolbeau schreef op 2019-12-11 08:19:
Le mer. 11 déc. 2019 à 03:20, Aneesh Kumar K.V
a écrit :
The PowerMac system we have internally was not able to recreate this.
To
On 11/12/19 4:21 pm, Daniel Axtens wrote:
> Hi Balbir,
>
>>> +Discontiguous memory can occur when you have a machine with memory spread
>>> +across multiple nodes. For example, on a Talos II with 64GB of RAM:
>>> +
>>> + - 32GB runs from 0x0 to 0x_0008__,
>>> + - then there's a
On Tue, Dec 10, 2019 at 02:34:30AM +, Y.b. Lu wrote:
> + Shawn,
>
> > -Original Message-
> > From: Michael Walle
> > Sent: Tuesday, December 10, 2019 8:06 AM
> > To: Yinbo Zhu
> > Cc: Ashish Kumar ; Alexandru Marginean
> > ; Alison Wang ;
> > Amit Jain (aj) ;
The last jump to free_exit in mm_iommu_do_alloc() happens after page
pointers in struct mm_iommu_table_group_mem_t were already converted to
physical addresses. Thus calling put_page() on these physical addresses
will likely crash. Convert physical addresses back to page pointers
during the error
On Tue 10-12-19 18:53:13, John Hubbard wrote:
> 1. Convert from get_user_pages() to pin_user_pages().
>
> 2. As required by pin_user_pages(), release these pages via
> put_user_page().
>
> Cc: Jan Kara
> Signed-off-by: John Hubbard
The patch looks good to me. You can add:
Reviewed-by: Jan
On Tue 10-12-19 18:53:16, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
>
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via unpin_user_page().
> The effect is similar to FOLL_GET, and
On 12/12/19 1:24 am, Daniel Axtens wrote:
> Hi Balbir,
>
> +Discontiguous memory can occur when you have a machine with memory spread
> +across multiple nodes. For example, on a Talos II with 64GB of RAM:
> +
> + - 32GB runs from 0x0 to 0x_0008__,
> + - then
PowerMac 7,3 G5 2.5 DP PCI-X Mid-2004 is affected with this bug. The
machine freezes at boot due to the new ppc64 kernel.
Regards,
Jeroen Diederen
Romain Dolbeau schreef op 2019-12-11 08:19:
Le mer. 11 déc. 2019 à 03:20, Aneesh Kumar K.V
a écrit :
The PowerMac system we have internally was
On Fri, 2019-12-06 at 10:47 +1100, Michael Ellerman wrote:
> Michael Ellerman writes:
> > Russell Currey writes:
> > > With CONFIG_STRICT_KERNEL_RWX=y and CONFIG_KPROBES=y, there will
> > > be one
> > > W+X page at boot by default. This can be tested with
> > > CONFIG_PPC_PTDUMP=y and
On Tue, Dec 10, 2019 at 07:43:24PM -0600, Michael Roth wrote:
> Quoting Ram Pai (2019-12-06 19:12:39)
> > Commit edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on
> > secure guests")
> > disabled dma_iommu_ops path, for secure VMs. Disabling dma_iommu_ops
> > path
From: "Gustavo L. F. Walbon"
[ Upstream commit 4e706af3cd8e1d0503c25332b30cad33c97ed442 ]
The issue was showing "Mitigation" message via sysfs whatever the
state of "RFI Flush", but it should show "Vulnerable" when it is
disabled.
If you have "L1D private" feature enabled and not "RFI Flush"
From: Nathan Chancellor
[ Upstream commit 465bfd9c44dea6b55962b5788a23ac87a467c923 ]
When building pseries_defconfig, building vdso32 errors out:
error: unknown target ABI 'elfv1'
This happens because -m32 in clang changes the target to 32-bit,
which does not allow the ABI to be changed.
From: "Aneesh Kumar K.V"
[ Upstream commit 75838a3290cd4ebbd1f567f310ba04b6ef017ce4 ]
If the hypervisor returned H_PTEG_FULL for H_ENTER hcall, retry a hash page
table
insert by removing a random entry from the group.
After some runtime, it is very well possible to find all the 8 hash page
From: Masahiro Yamada
[ Upstream commit a8de1304b7df30e3a14f2a8b9709bb4ff31a0385 ]
The DTC v1.5.1 added references to (U)INT32_MAX.
This is no problem for user-space programs since defines
(U)INT32_MAX along with (u)int32_t.
For the kernel space, libfdt_env.h needs to be adjusted before we
From: Anthony Steinhauser
[ Upstream commit 8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d ]
Some PowerPC CPUs are vulnerable to L1TF to the same extent as to
Meltdown. It is also mitigated by flushing the L1D on privilege
transition.
Currently the sysfs gives a false negative on L1TF on CPUs that I
From: Michael Ellerman
[ Upstream commit eb8e20f89093b64f48975c74ccb114e6775cee22 ]
accumulate_stolen_time() is called prior to interrupt state being
reconciled, which can trip the warning in arch_local_irq_restore():
WARNING: CPU: 5 PID: 1017 at arch/powerpc/kernel/irq.c:258
From: Michael Ellerman
[ Upstream commit e44ff9ea8f4c8a90c82f7b85bd4f5e497c841960 ]
Some of our scripts are passed $objdump and then call it as
"$objdump". This doesn't work if it contains spaces because we're
using ccache, for example you get errors such as:
On 12/11/19 9:32 AM, Thomas Falcon wrote:
This conditional is missing a bang, with the intent
being to break when the retry count reaches zero.
Fixes: 476d96ca9c ("ibmvnic: Bound waits for device queries")
Suggested-by: Juliet Kim
Signed-off-by: Thomas Falcon
---
Excuse me, disregard this
On 12/5/19 3:32 AM, Srikar Dronamraju wrote:
> With commit 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted
> vCPUs"), scheduler avoids preempted vCPUs to schedule tasks on wakeup.
> This leads to wrong choice of CPU, which in-turn leads to larger wakeup
> latencies. Eventually, it
From: "Aneesh Kumar K.V"
[ Upstream commit 16f6b67cf03cb43db7104acb2ca877bdc2606c92 ]
With large memory (8TB and more) hotplug, we can get soft lockup
warnings as below. These were caused by a long loop without any
explicit cond_resched which is a problem for !PREEMPT kernels.
Avoid this using
From: David Hildenbrand
[ Upstream commit 7d8212747435c534c8d564fbef4541a463c976ff ]
When unloading the module, one gets
[ cut here ]
Device 'cmm0' does not have a release() function, it is broken and must be
fixed. See Documentation/kobject.txt.
WARNING: CPU: 0
From: Michael Ellerman
[ Upstream commit e44ff9ea8f4c8a90c82f7b85bd4f5e497c841960 ]
Some of our scripts are passed $objdump and then call it as
"$objdump". This doesn't work if it contains spaces because we're
using ccache, for example you get errors such as:
From: David Hildenbrand
[ Upstream commit 7d8212747435c534c8d564fbef4541a463c976ff ]
When unloading the module, one gets
[ cut here ]
Device 'cmm0' does not have a release() function, it is broken and must be
fixed. See Documentation/kobject.txt.
WARNING: CPU: 0
Hello,
I'm seeing a set of build warnings on the 5.5-rc1 kernel:
WARNING: vmlinux.o(.text+0x31e4): Section mismatch in reference from the
variable __boot_from_prom to the function .init.text:prom_init()
The function __boot_from_prom() references
the function __init prom_init().
This is often
From: Michael Ellerman
[ Upstream commit eb8e20f89093b64f48975c74ccb114e6775cee22 ]
accumulate_stolen_time() is called prior to interrupt state being
reconciled, which can trip the warning in arch_local_irq_restore():
WARNING: CPU: 5 PID: 1017 at arch/powerpc/kernel/irq.c:258
From: Michael Ellerman
[ Upstream commit e44ff9ea8f4c8a90c82f7b85bd4f5e497c841960 ]
Some of our scripts are passed $objdump and then call it as
"$objdump". This doesn't work if it contains spaces because we're
using ccache, for example you get errors such as:
From: Sam Bobroff
[ Upstream commit de84ffc3ccbeec3678f95a3d898fc188efa0d9c5 ]
Currently when an EEH error is detected, the system log receives the
same (or almost the same) message twice:
EEH: PHB#0 failure detected, location: N/A
EEH: PHB#0 failure detected, location: N/A
or
EEH:
From: Christophe Leroy
[ Upstream commit 77693a5fb57be4606a6024ec8e3076f9499b906b ]
Modify back __set_fixmap() to using __fix_to_virt() instead
of fix_to_virt() otherwise the following happens because it
seems GCC doesn't see idx as a builtin const.
CC mm/early_ioremap.o
In file
From: "Aneesh Kumar K.V"
[ Upstream commit 75838a3290cd4ebbd1f567f310ba04b6ef017ce4 ]
If the hypervisor returned H_PTEG_FULL for H_ENTER hcall, retry a hash page
table
insert by removing a random entry from the group.
After some runtime, it is very well possible to find all the 8 hash page
From: "Gustavo L. F. Walbon"
[ Upstream commit 4e706af3cd8e1d0503c25332b30cad33c97ed442 ]
The issue was showing "Mitigation" message via sysfs whatever the
state of "RFI Flush", but it should show "Vulnerable" when it is
disabled.
If you have "L1D private" feature enabled and not "RFI Flush"
From: Anthony Steinhauser
[ Upstream commit 8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d ]
Some PowerPC CPUs are vulnerable to L1TF to the same extent as to
Meltdown. It is also mitigated by flushing the L1D on privilege
transition.
Currently the sysfs gives a false negative on L1TF on CPUs that I
From: David Hildenbrand
[ Upstream commit 7d8212747435c534c8d564fbef4541a463c976ff ]
When unloading the module, one gets
[ cut here ]
Device 'cmm0' does not have a release() function, it is broken and must be
fixed. See Documentation/kobject.txt.
WARNING: CPU: 0
From: "Gustavo L. F. Walbon"
[ Upstream commit 4e706af3cd8e1d0503c25332b30cad33c97ed442 ]
The issue was showing "Mitigation" message via sysfs whatever the
state of "RFI Flush", but it should show "Vulnerable" when it is
disabled.
If you have "L1D private" feature enabled and not "RFI Flush"
This conditional is missing a bang, with the intent
being to break when the retry count reaches zero.
Fixes: 476d96ca9c ("ibmvnic: Bound waits for device queries")
Suggested-by: Juliet Kim
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
1 file changed, 1
Hi Balbir,
+Discontiguous memory can occur when you have a machine with memory spread
+across multiple nodes. For example, on a Talos II with 64GB of RAM:
+
+ - 32GB runs from 0x0 to 0x_0008__,
+ - then there's a gap,
+ - then the final 32GB runs from
On Tue, Dec 10, 2019 at 2:17 AM Frank Rowand wrote:
>
> On 12/9/19 7:51 PM, Rob Herring wrote:
> > On Mon, Dec 9, 2019 at 7:35 AM Sebastian Andrzej Siewior
> > wrote:
> >>
> >> On 2019-12-05 20:01:41 [-0600], Frank Rowand wrote:
> >>> Is there a memory usage issue for the systems that led to
From: Michael Ellerman
[ Upstream commit eb8e20f89093b64f48975c74ccb114e6775cee22 ]
accumulate_stolen_time() is called prior to interrupt state being
reconciled, which can trip the warning in arch_local_irq_restore():
WARNING: CPU: 5 PID: 1017 at arch/powerpc/kernel/irq.c:258
From: Nathan Chancellor
[ Upstream commit 465bfd9c44dea6b55962b5788a23ac87a467c923 ]
When building pseries_defconfig, building vdso32 errors out:
error: unknown target ABI 'elfv1'
This happens because -m32 in clang changes the target to 32-bit,
which does not allow the ABI to be changed.
From: "Aneesh Kumar K.V"
[ Upstream commit 16f6b67cf03cb43db7104acb2ca877bdc2606c92 ]
With large memory (8TB and more) hotplug, we can get soft lockup
warnings as below. These were caused by a long loop without any
explicit cond_resched which is a problem for !PREEMPT kernels.
Avoid this using
From: Masahiro Yamada
[ Upstream commit a8de1304b7df30e3a14f2a8b9709bb4ff31a0385 ]
The DTC v1.5.1 added references to (U)INT32_MAX.
This is no problem for user-space programs since defines
(U)INT32_MAX along with (u)int32_t.
For the kernel space, libfdt_env.h needs to be adjusted before we
From: Vaibhav Jain
[ Upstream commit 612ee81b9461475b5a5612c2e8d71559dd3c7920 ]
A validation check to prevent out of bounds read/write inside
functions papr_scm_meta_{get,set}() is off-by-one that prevent reads
and writes to the last byte of the label area.
This bug manifests as a failure to
From: "Aneesh Kumar K.V"
[ Upstream commit 75838a3290cd4ebbd1f567f310ba04b6ef017ce4 ]
If the hypervisor returned H_PTEG_FULL for H_ENTER hcall, retry a hash page
table
insert by removing a random entry from the group.
After some runtime, it is very well possible to find all the 8 hash page
From: Anthony Steinhauser
[ Upstream commit 8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d ]
Some PowerPC CPUs are vulnerable to L1TF to the same extent as to
Meltdown. It is also mitigated by flushing the L1D on privilege
transition.
Currently the sysfs gives a false negative on L1TF on CPUs that I
From: "Aneesh Kumar K.V"
[ Upstream commit d7e02f7b7991dbe14a2acfb0e53d675cd149001c ]
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
From: "Aneesh Kumar K.V"
[ Upstream commit 16f6b67cf03cb43db7104acb2ca877bdc2606c92 ]
With large memory (8TB and more) hotplug, we can get soft lockup
warnings as below. These were caused by a long loop without any
explicit cond_resched which is a problem for !PREEMPT kernels.
Avoid this using
From: Masahiro Yamada
[ Upstream commit a8de1304b7df30e3a14f2a8b9709bb4ff31a0385 ]
The DTC v1.5.1 added references to (U)INT32_MAX.
This is no problem for user-space programs since defines
(U)INT32_MAX along with (u)int32_t.
For the kernel space, libfdt_env.h needs to be adjusted before we
From: Anthony Steinhauser
[ Upstream commit 8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d ]
Some PowerPC CPUs are vulnerable to L1TF to the same extent as to
Meltdown. It is also mitigated by flushing the L1D on privilege
transition.
Currently the sysfs gives a false negative on L1TF on CPUs that I
From: "Aneesh Kumar K.V"
[ Upstream commit 16f6b67cf03cb43db7104acb2ca877bdc2606c92 ]
With large memory (8TB and more) hotplug, we can get soft lockup
warnings as below. These were caused by a long loop without any
explicit cond_resched which is a problem for !PREEMPT kernels.
Avoid this using
From: David Hildenbrand
[ Upstream commit 7d8212747435c534c8d564fbef4541a463c976ff ]
When unloading the module, one gets
[ cut here ]
Device 'cmm0' does not have a release() function, it is broken and must be
fixed. See Documentation/kobject.txt.
WARNING: CPU: 0
On 2019-12-11 09:33, Justin Forbes wrote:
> On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
> wrote:
> >
> > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> > > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann
> > > wrote:
> > > >
> > > > On Mon, Dec 02, 2019 at
On Wed, Dec 11, 2019 at 09:33:53AM -0600, Justin Forbes wrote:
> On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
> wrote:
> >
> > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> > > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann
> > > wrote:
> > > >
> > > > On
As the number of FADump sysfs files increases it is hard to manage all of
them inside /sys/kernel directory. It's better to have all the FADump
related sysfs files in a dedicated directory /sys/kernel/fadump. But in
order to maintain backward compatibility a symlink has been added for every
sysfs
From: Michael Ellerman
[ Upstream commit eb8e20f89093b64f48975c74ccb114e6775cee22 ]
accumulate_stolen_time() is called prior to interrupt state being
reconciled, which can trip the warning in arch_local_irq_restore():
WARNING: CPU: 5 PID: 1017 at arch/powerpc/kernel/irq.c:258
From: "Aneesh Kumar K.V"
[ Upstream commit 75838a3290cd4ebbd1f567f310ba04b6ef017ce4 ]
If the hypervisor returned H_PTEG_FULL for H_ENTER hcall, retry a hash page
table
insert by removing a random entry from the group.
After some runtime, it is very well possible to find all the 8 hash page
From: David Hildenbrand
[ Upstream commit 7d8212747435c534c8d564fbef4541a463c976ff ]
When unloading the module, one gets
[ cut here ]
Device 'cmm0' does not have a release() function, it is broken and must be
fixed. See Documentation/kobject.txt.
WARNING: CPU: 0
On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
wrote:
>
> On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> > On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann wrote:
> > >
> > > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
> > > > Aurelien Jarno
The __compat_only_sysfs_link_entry_to_kobj function creates a symlink to a
kobject but doesn't provide an option to change the symlink file name.
This patch adds a wrapper function compat_only_sysfs_link_entry_to_kobj
that extends the __compat_only_sysfs_link_entry_to_kobj functionality
which
The /sys/firmware/opal/core and /sys/kernel/fadump_release_opalcore sysfs
files are used to export and release the OPAL memory on PowerNV platform.
let's organize them into a new kobject under /sys/firmware/opal/mpipl/
directory.
A symlink is added to maintain the backward compatibility for
https://bugzilla.kernel.org/show_bug.cgi?id=205099
Christophe Leroy (christophe.le...@c-s.fr) changed:
What|Removed |Added
CC|
From: Masahiro Yamada
[ Upstream commit a8de1304b7df30e3a14f2a8b9709bb4ff31a0385 ]
The DTC v1.5.1 added references to (U)INT32_MAX.
This is no problem for user-space programs since defines
(U)INT32_MAX along with (u)int32_t.
For the kernel space, libfdt_env.h needs to be adjusted before we
This conditional is missing a bang, with the intent
being to break when the retry count reaches zero.
Fixes: 476d96ca9c ("ibmvnic: Bound waits for device queries")
Suggested-by: Juliet Kim
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 +-
1 file changed, 1
Add missing ABI documentation for existing FADump sysfs files.
Signed-off-by: Sourabh Jain
---
Documentation/ABI/testing/sysfs-kernel-fadump_enabled | 7 +++
Documentation/ABI/testing/sysfs-kernel-fadump_registered | 8
Documentation/ABI/testing/sysfs-kernel-fadump_release_mem
Currently, FADump sysfs files are present inside /sys/kernel directory.
But as the number of FADump sysfs file increases it is not a good idea to
push all of them in /sys/kernel directory. It is better to have separate
directory to keep all the FADump sysfs files.
Patch series reorganizes the
Add a deprecation note in FADump sysfs ABI documentation files and move
them from ABI/testing to ABI/obsolete directory.
Signed-off-by: Sourabh Jain
---
.../ABI/{testing => obsolete}/sysfs-kernel-fadump_enabled | 2 ++
.../{testing => obsolete}/sysfs-kernel-fadump_registered | 2 ++
Quoting Alexey Kardashevskiy (2019-12-11 02:36:29)
>
>
> On 11/12/2019 12:43, Michael Roth wrote:
> > Quoting Ram Pai (2019-12-06 19:12:39)
> >> Commit edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on
> >> secure guests")
> >> disabled dma_iommu_ops path, for
From: "Gustavo L. F. Walbon"
[ Upstream commit 4e706af3cd8e1d0503c25332b30cad33c97ed442 ]
The issue was showing "Mitigation" message via sysfs whatever the
state of "RFI Flush", but it should show "Vulnerable" when it is
disabled.
If you have "L1D private" feature enabled and not "RFI Flush"
From: Michael Ellerman
[ Upstream commit eb8e20f89093b64f48975c74ccb114e6775cee22 ]
accumulate_stolen_time() is called prior to interrupt state being
reconciled, which can trip the warning in arch_local_irq_restore():
WARNING: CPU: 5 PID: 1017 at arch/powerpc/kernel/irq.c:258
From: Anthony Steinhauser
[ Upstream commit 8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d ]
Some PowerPC CPUs are vulnerable to L1TF to the same extent as to
Meltdown. It is also mitigated by flushing the L1D on privilege
transition.
Currently the sysfs gives a false negative on L1TF on CPUs that I
From: "Gustavo L. F. Walbon"
[ Upstream commit 4e706af3cd8e1d0503c25332b30cad33c97ed442 ]
The issue was showing "Mitigation" message via sysfs whatever the
state of "RFI Flush", but it should show "Vulnerable" when it is
disabled.
If you have "L1D private" feature enabled and not "RFI Flush"
Add a sys interface to allow querying the memory reserved by FADump for
saving the crash dump.
Also added Documentation/ABI for the new sysfs file.
Signed-off-by: Sourabh Jain
---
Documentation/ABI/testing/sysfs-kernel-fadump| 7 +++
Documentation/powerpc/firmware-assisted-dump.rst | 5
On Wed, Dec 11, 2019 at 12:07:17PM -0600, Michael Roth wrote:
> > io_tlb_start/io_tlb_end are only guaranteed to stay within 4GB and our
> > default DMA window is 1GB (KVM) or 2GB (PowerVM), ok, we can define
> > ARCH_LOW_ADDRESS_LIMIT as 1GB.
>
> True, and limiting allocations to under 1GB might
From: Masahiro Yamada
[ Upstream commit a8de1304b7df30e3a14f2a8b9709bb4ff31a0385 ]
The DTC v1.5.1 added references to (U)INT32_MAX.
This is no problem for user-space programs since defines
(U)INT32_MAX along with (u)int32_t.
For the kernel space, libfdt_env.h needs to be adjusted before we
On Wed, Dec 11, 2019 at 10:01 AM Thadeu Lima de Souza Cascardo
wrote:
>
> On Wed, Dec 11, 2019 at 09:33:53AM -0600, Justin Forbes wrote:
> > On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
> > wrote:
> > >
> > > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> > > >
Quoting Alexey Kardashevskiy (2019-12-11 02:15:44)
>
>
> On 11/12/2019 02:35, Ram Pai wrote:
> > On Tue, Dec 10, 2019 at 04:32:10PM +1100, Alexey Kardashevskiy wrote:
> >>
> >>
> >> On 10/12/2019 16:12, Ram Pai wrote:
> >>> On Tue, Dec 10, 2019 at 02:07:36PM +1100, Alexey Kardashevskiy wrote:
>
On 12/12/2019 07:31, Michael Roth wrote:
> Quoting Alexey Kardashevskiy (2019-12-11 02:15:44)
>>
>>
>> On 11/12/2019 02:35, Ram Pai wrote:
>>> On Tue, Dec 10, 2019 at 04:32:10PM +1100, Alexey Kardashevskiy wrote:
On 10/12/2019 16:12, Ram Pai wrote:
> On Tue, Dec 10, 2019 at
On Tue, 10 Dec 2019 18:53:03 -0800
John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
Just a couple of nits on the documentation patch
> +++ b/Documentation/core-api/pin_user_pages.rst
> @@ -0,0 +1,232 @@
> +..
On 12/11/19 12:57 PM, Jonathan Corbet wrote:
> On Tue, 10 Dec 2019 18:53:03 -0800
> John Hubbard wrote:
>
>> Introduce pin_user_pages*() variations of get_user_pages*() calls,
>> and also pin_longterm_pages*() variations.
>
> Just a couple of nits on the documentation patch
>
>> +++
On Wed, Dec 11, 2019 at 07:15:44PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 11/12/2019 02:35, Ram Pai wrote:
> > On Tue, Dec 10, 2019 at 04:32:10PM +1100, Alexey Kardashevskiy wrote:
> >>
..snip..
> >> As discussed in slack, by default we do not need to clear the entire TCE
> >> table and we
With OPAL using the same endianness, same stack, and with OS
callbacks, it looks relatively easy to provide a CPU idle driver.
The Linux sreset interrupt won't have to change, if it registers
almost like isa300_idle_stop_mayloss as the os_stop function,
then skiboot will call that to stop, and it
On 12/12/2019 09:47, Alexey Kardashevskiy wrote:
>
>
> On 12/12/2019 07:31, Michael Roth wrote:
>> Quoting Alexey Kardashevskiy (2019-12-11 02:15:44)
>>>
>>>
>>> On 11/12/2019 02:35, Ram Pai wrote:
On Tue, Dec 10, 2019 at 04:32:10PM +1100, Alexey Kardashevskiy wrote:
>
>
> On
Thadeu Lima de Souza Cascardo writes:
> On Wed, Dec 11, 2019 at 09:33:53AM -0600, Justin Forbes wrote:
>> On Tue, Dec 10, 2019 at 4:26 PM Thadeu Lima de Souza Cascardo
>> wrote:
>> >
>> > On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
>> > > On Mon, Dec 2, 2019 at 3:37 AM Daniel
On Mon, 2019-12-09 at 02:38 -0600, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Dec 09, 2019 at 06:37:09AM +0100, Christophe Leroy wrote:
> > What do you mean by NX ?
>
> It is the Power9 "Nest Accelerator". The patch series should ideally
> mention that right at the start, yeah.
Thanks, NX
[PATCH V2 00/13] powerpc/vas: Page fault handling for user space NX requests
On power9, Virtual Accelerator Switchboard (VAS) allows user space or
kernel to communicate with Nest Accelerator (NX) directly using COPY/PASTE
instructions. NX provides verious functionalities such as compression,
[ trimmed CC a bit ]
Peter Zijlstra writes:
> On Fri, Dec 06, 2019 at 11:46:11PM +1100, Michael Ellerman wrote:
...
> you write:
>
> "Currently bitops-instrumented.h assumes that the architecture provides
> atomic, non-atomic and locking bitops (e.g. both set_bit and __set_bit).
> This is true
On 12/11/19 3:28 AM, Jan Kara wrote:
...
The patch looks mostly good to me now. Just a few smaller comments below.
Suggested-by: Jan Kara
Suggested-by: Jérôme Glisse
Reviewed-by: Jan Kara
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
I think you inherited here the Reviewed-by tags
91 matches
Mail list logo
