On Fri, 18 Jun 2021 01:50:59 +1000, Nicholas Piggin wrote:
> This series attempts to improve the speed of interrupts and system calls
> in three major ways.
>
> Firstly, the SRR/HSRR registers do not need to be reloaded if they were
> clobbered for the duration of the interrupt and the return NIP
On Wed, 23 Jun 2021 12:15:28 +1000, Nicholas Piggin wrote:
> PowerVM will not arbitrarily oversubscribe or stop guests, page out the
> guest kernel text to a NFS volume connected by carrier pigeon to abacus
> based storage, etc., as a KVM host might. So PowerVM guests are not
> likely to be killed
On Mon, 3 May 2021 21:18:22 +1000, Nicholas Piggin wrote:
> PowerVM will not arbitrarily oversubscribe or stop guests, page out the
> guest kernel text to a NFS volume connected by carrier pigeon to abacus
> based storage, etc., as a KVM host might. So PowerVM guests are not
> likely to be killed b
On Wed, 23 Jun 2021 14:12:45 +1000, Nicholas Piggin wrote:
> printk_safe_flush_on_panic() has special lock breaking code for the
> case where we panic()ed with the console lock held. It relies on
> panic IPI causing other CPUs to mark themselves offline.
>
> Do as most other architectures do.
>
>
On Wed, 23 Jun 2021 13:29:09 +1000, Nicholas Piggin wrote:
> 32-bit platforms don't have irq soft masking.
Applied to powerpc/next.
[1/1] powerpc: Make PPC_IRQ_SOFT_MASK_DEBUG depend on PPC64
https://git.kernel.org/powerpc/c/f5f48e8cb93f4acd77411df0327b61066985bea8
cheers
On Wed, 23 Jun 2021 12:29:24 +1000, Nicholas Piggin wrote:
> The caller has been moved to C after irq soft-mask state has been
> reconciled, and Linux irqs have been marked as disabled, so this
> does not have to play games with irq internals.
Applied to powerpc/next.
[1/1] powerpc/64s: accumulat
On Thu, 24 Jun 2021 22:34:20 +1000, Michael Ellerman wrote:
> When using the Radix MMU our PGD is always 64K, and must be naturally
> aligned.
>
> For a 4K page size kernel that means page alignment of swapper_pg_dir is
> not sufficient, leading to failure to boot.
>
> Use the existing MAX_PTRS_P
On Mon, 21 Jun 2021 16:49:37 +1000, Michael Ellerman wrote:
> In a subsequent patch we'd like to have something like a strscpy_pad()
> implementation usable in prom_init.c.
>
> Currently we have a strcpy() implementation with only one caller, so
> convert it into strscpy_pad() and update the calle
On Tue, 22 Jun 2021 10:39:22 -0300, Daniel Henrique Barboza wrote:
> After a successful dlpar_add_lmb() call the LMB is marked as reserved.
> Later on, depending whether we added enough LMBs or not, we rely on
> the marked LMBs to see which ones might need to be removed, and we
> remove the reserva
On Tue, 22 Jun 2021 10:39:20 -0300, Daniel Henrique Barboza wrote:
> These are a couple of cleanups for the dlpar_memory_add* functions
> that are similar to those I did a month or so ago in
> dlpar_memory_remove_by_count and dlpar_memory_remove_by_ic.
>
>
>
> Daniel Henrique Barboza (3):
> po
On Wed, 16 Jun 2021 16:43:03 +0300, Andy Shevchenko wrote:
> Parse to and export from UUID own type, before dereferencing.
> This also fixes wrong comment (Little Endian UUID is something else)
> and should eliminate the direct strict types assignments.
Applied to powerpc/next.
[1/1] powerpc/papr
On Fri, Jun 25, 2021 at 11:16:08AM +0530, Srikar Dronamraju wrote:
> * Bharata B Rao [2021-06-24 21:25:09]:
>
> > A PowerPC KVM guest gets the following BUG message when booting
> > linux-next-20210623:
> >
> > smp: Bringing up secondary CPUs ...
> > BUG: scheduling while atomic: swapper/1/0/0x0
* Bharata B Rao [2021-06-24 21:25:09]:
> A PowerPC KVM guest gets the following BUG message when booting
> linux-next-20210623:
>
> smp: Bringing up secondary CPUs ...
> BUG: scheduling while atomic: swapper/1/0/0x
> no locks held by swapper/1/0.
> Modules linked in:
> CPU: 1 PID: 0 Comm
Pagewalk ignores hugepd entries and walk down the tables
as if it was traditionnal entries, leading to crazy result.
Add walk_hugepd_range() and use it to walk hugepage tables.
Signed-off-by: Christophe Leroy
Reviewed-by: Steven Price
---
v3:
- Rebased on next-20210624 (no change since v2
Le 25/06/2021 à 06:45, Michael Ellerman a écrit :
Christophe Leroy writes:
Hi Michael,
Le 19/04/2021 à 12:47, Christophe Leroy a écrit :
Pagewalk ignores hugepd entries and walk down the tables
as if it was traditionnal entries, leading to crazy result.
Add walk_hugepd_range() and use it
There are patches in flight to break the dependency between asm/irq.h
and linux/irqdomain.h, which would break compilation of vas.c because it
needs the declaration of irq_create_mapping() etc.
So add an explicit include of irqdomain.h to avoid that becoming a
problem in future.
Reported-by: Step
Christophe Leroy writes:
> Le 24/06/2021 à 12:59, Naveen N. Rao a écrit :
>> Christophe Leroy wrote:
>>> From: Naveen N. Rao
>>>
>>> Trying to use a kprobe on ppc32 results in the below splat:
>>> BUG: Unable to handle kernel data access on read at 0x7c0802a6
>>> Faulting instruction addr
Christophe Leroy writes:
> Hi Michael,
>
> Le 19/04/2021 à 12:47, Christophe Leroy a écrit :
>> Pagewalk ignores hugepd entries and walk down the tables
>> as if it was traditionnal entries, leading to crazy result.
>>
>> Add walk_hugepd_range() and use it to walk hugepage tables.
>
> I see you t
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: dc4225b1afe8424b3fdf56599cdac283be683c69 Automatic merge of
'next' into merge (2021-06-25 00:45)
elapsed time: 734m
configs tested: 105
configs skipped: 3
The following configs have been built su
On Fri, Jun 25, 2021 at 3:20 AM Konrad Rzeszutek Wilk
wrote:
>
> On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> > This series implements mitigations for lack of DMA access control on
> > systems without an IOMMU, which could result in the DMA accessing the
> > system memory at une
Excerpts from Paolo Bonzini's message of June 25, 2021 1:35 am:
> On 24/06/21 14:57, Nicholas Piggin wrote:
>> KVM: Fix page ref underflow for regions with valid but non-refcounted pages
>
> It doesn't really fix the underflow, it disallows mapping them in the
> first place. Since in principle t
On Thu, Jun 24, 2021, Paolo Bonzini wrote:
> On 24/06/21 10:43, Nicholas Piggin wrote:
> > Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> > > From: David Stevens
> >
> > Changelog? This looks like a bug, should it have a Fixes: tag?
>
> Probably has been there forever... The b
Hi Michael,
Le 19/04/2021 à 12:47, Christophe Leroy a écrit :
Pagewalk ignores hugepd entries and walk down the tables
as if it was traditionnal entries, leading to crazy result.
Add walk_hugepd_range() and use it to walk hugepage tables.
I see you took patch 2 and 3 of the series.
Do you ex
On Thu, Jun 24, 2021 at 11:58:57PM +0800, Claire Chang wrote:
> On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> > >
> > >
> > > On 6/24/2021 7:48 AM, Will Deacon wrote:
> > > > Ok, diff below which attempts to tack
On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data le
On Thu 2021-06-24 13:17:45, John Ogness wrote:
> With @logbuf_lock removed, the high level printk functions for
> storing messages are lockless. Messages can be stored from any
> context, so there is no need for the NMI and safe buffers anymore.
> Remove the NMI and safe buffers.
>
> Although the
On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
wrote:
>
> On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> >
> >
> > On 6/24/2021 7:48 AM, Will Deacon wrote:
> > > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > > well. Qian Cai -- please can you try
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
drivers/of/address.c| 33 +
drivers/o
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
.../
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpec
Add the functions, swiotlb_{alloc,free} and is_swiotlb_for_alloc to
support the memory allocation from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and u
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 35 ---
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 17 +
1 file chang
On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
>
>
> On 6/24/2021 7:48 AM, Will Deacon wrote:
> > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > well. Qian Cai -- please can you try with these changes?
>
> This works fine.
Cool. Let me squash this patch i
Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
A
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/gpu/drm/i915/gem/i915_gem
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/iommu/dma-iommu.c | 12 ++
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/base/core.c| 4 ++
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
kernel/dma/swiotlb.c | 50
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for Wi
Hi,
A PowerPC KVM guest gets the following BUG message when booting
linux-next-20210623:
smp: Bringing up secondary CPUs ...
BUG: scheduling while atomic: swapper/1/0/0x
no locks held by swapper/1/0.
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.13.0-rc7-next-20210623
Cal
On 2021-06-24, Petr Mladek wrote:
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -1852,7 +1839,7 @@ static int console_trylock_spinning(void)
>> if (console_trylock())
>> return 1;
>>
>> -printk_safe_enter_irqsave(flags);
>> +local_irq_save(flags)
On 24/06/21 14:57, Nicholas Piggin wrote:
KVM: Fix page ref underflow for regions with valid but non-refcounted pages
It doesn't really fix the underflow, it disallows mapping them in the
first place. Since in principle things can break, I'd rather be
explicit, so let's go with "KVM: do not
On 6/24/2021 7:48 AM, Will Deacon wrote:
> Ok, diff below which attempts to tackle the offset issue I mentioned as
> well. Qian Cai -- please can you try with these changes?
This works fine.
>
> Will
>
> --->8
>
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index 175b6c
On Fri, 18 Jun 2021 13:42:53 +1000, Paul Mackerras wrote:
> This series of patches adds support for the Microwatt soft-core.
> Microwatt is an open-source 64-bit Power ISA processor written in VHDL
> which targets medium-sized FPGAs such as the Xilinx Artix-7 or the
> Lattice ECP5. Microwatt curre
On Tue, 18 May 2021 00:03:55 +1000, Nicholas Piggin wrote:
> POWER9 and POWER10 asynchronous machine checks due to stores have their
> cause reported in SRR1 but SRR1[42] is set, which in other cases
> indicates DSISR cause.
>
> Check for these cases and clear SRR1[42], so the cause matching uses
On Fri, 11 Jun 2021 21:11:04 +1000, Nicholas Piggin wrote:
> This prevents spurious rebuilds of the lds and then wrappers.
Applied to powerpc/next.
[1/1] powerpc/boot: add zImage.lds to targets
https://git.kernel.org/powerpc/c/710e682286784b50b882fc4befdf83c587059211
cheers
On Mon, 3 May 2021 23:02:39 +1000, Nicholas Piggin wrote:
> This series adds a few missing bits added to recent pseries
> H_GET_CPU_CHARACTERISTICS and implements them, also removes
> a restriction from powernv for some of the flushes.
>
> This is tested mianly in qemu where I just submitted a pat
On Wed, 9 Jun 2021 11:34:22 +1000, Jordan Niethe wrote:
> Adding more Strict RWX support on powerpc, in particular Strict Module RWX.
> It is now rebased on ppc next.
>
> For reference the previous revision is available here:
> https://lore.kernel.org/linuxppc-dev/20210517032810.129949-1-jniet...@
On Thu, 17 Jun 2021 13:24:31 -0700, Haren Myneni wrote:
> Virtual Accelerator Switchboard (VAS) allows kernel subsystems
> and user space processes to directly access the Nest Accelerator
> (NX) engines which provides HW compression. The true user mode
> VAS/NX support on PowerNV is already include
On Wed, 26 May 2021 22:58:51 +1000, Nicholas Piggin wrote:
> Similar to commit 25edcc50d76c ("KVM: PPC: Book3S HV: Save and restore
> FSCR in the P9 path"), ensure the P7/8 path saves and restores the host
> FSCR. The logic explained in that patch actually applies there to the
> old path well: a co
On Wed, 2 Jun 2021 14:04:41 +1000, Nicholas Piggin wrote:
> The POWER9 vCPU TLB management code assumes all threads in a core share
> a TLB, and that TLBIEL execued by one thread will invalidate TLBs for
> all threads. This is not the case for SMT8 capable POWER9 and POWER10
> (big core) processors
On Fri, 28 May 2021 19:07:20 +1000, Nicholas Piggin wrote:
> Git tree here
>
> https://github.com/npiggin/linux/tree/kvm-in-c-5.14-1
>
> This series applies to upstream plus a couple of KVM regression fixes
> not yet in powerpc tree, which are included in the above git tree.
>
> [...]
Applied t
On Mon, 21 Jun 2021 11:24:40 -0700, Nathan Chancellor wrote:
> LLVM does not emit optimal byteswap assembly, which results in high
> stack usage in kvmhv_enter_nested_guest() due to the inlining of
> byteswap_pt_regs(). With LLVM 12.0.0:
>
> arch/powerpc/kvm/book3s_hv_nested.c:289:6: error: stack
On Mon, 21 Jun 2021 14:19:57 +0530, Bharata B Rao wrote:
> This patchset adds support for the new hcall H_RPT_INVALIDATE
> and replaces the nested tlb flush calls with this new hcall
> if support for the same exists.
>
> Changes in v8:
> -
> - Used tlb_single_page_flush_ceiling in the
Excerpts from Paolo Bonzini's message of June 24, 2021 10:41 pm:
> On 24/06/21 13:42, Nicholas Piggin wrote:
>> Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
>>> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
KVM supports mapping VM_IO and VM_PFNMAP memory
On 24/06/21 13:42, Nicholas Piggin wrote:
Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
follow_pte in gfn_to_pfn. However, the resolved pfn
When using the Radix MMU our PGD is always 64K, and must be naturally
aligned.
For a 4K page size kernel that means page alignment of swapper_pg_dir is
not sufficient, leading to failure to boot.
Use the existing MAX_PTRS_PER_PGD which has the correct value, and
avoids us hard-coding 64K here.
F
On 24/06/21 13:42, Nicholas Piggin wrote:
+static int kvm_try_get_pfn(kvm_pfn_t pfn)
+{
+ if (kvm_is_reserved_pfn(pfn))
+ return 1;
So !pfn_valid would always return true. Yeah, this should work and is
certainly appealing!
Paolo
+ return get_page_unless_zero(pfn
On Thu, Jun 24, 2021 at 12:34:09PM +0100, Robin Murphy wrote:
> On 2021-06-24 12:18, Will Deacon wrote:
> > On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
> > > On 2021-06-24 07:05, Claire Chang wrote:
> > > > On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
> > > > >
> > >
Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
>> KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
>> follow_pte in gfn_to_pfn. However, the resolved pfns may not have
>> assoicated struct pa
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/s
All NMI contexts are handled the same as the safe context: store the
message and defer printing. There is no need to have special NMI
context tracking for this. Using in_nmi() is enough.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
arch/arm/kernel/smp.c | 2 --
arch/powerpc/ke
With @logbuf_lock removed, the high level printk functions for
storing messages are lockless. Messages can be stored from any
context, so there is no need for the NMI and safe buffers anymore.
Remove the NMI and safe buffers.
Although the safe buffers are removed, the NMI and safe context
tracking
Hi,
Here is v3 of a series to remove the safe buffers. v2 can be
found here [0]. The safe buffers are no longer needed because
messages can be stored directly into the log buffer from any
context.
However, the safe buffers also provided a form of recursion
protection. For that reason, explicit re
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
> On 2021-06-24 07:05, Claire Chang wrote:
> > On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
> > >
> > > On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > > > is_swiotlb_force_bounce at
> > > > /usr/src/linux-ne
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
is_swiotlb_force_bounce() was the new function introduced i
Le 24/06/2021 à 12:59, Naveen N. Rao a écrit :
Christophe Leroy wrote:
From: Naveen N. Rao
Trying to use a kprobe on ppc32 results in the below splat:
BUG: Unable to handle kernel data access on read at 0x7c0802a6
Faulting instruction address: 0xc002e9f0
Oops: Kernel access of b
Christophe Leroy wrote:
From: Naveen N. Rao
Trying to use a kprobe on ppc32 results in the below splat:
BUG: Unable to handle kernel data access on read at 0x7c0802a6
Faulting instruction address: 0xc002e9f0
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PowerPC 4
On 6/24/21 4:03 PM, Laurent Dufour wrote:
Hi Aneesh,
A little bit of wordsmithing below...
Le 17/06/2021 à 18:51, Aneesh Kumar K.V a écrit :
PAPR interface currently supports two different ways of communicating
resource
grouping details to the OS. These are referred to as Form 0 and Form 1
as
In the function fsl_xcvr__probe(), when get irq failed,
the function platform_get_irq() logs an error message, so remove
redundant message here.
Signed-off-by: Tang Bin
---
sound/soc/fsl/fsl_xcvr.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_xcvr.c b/
Excerpts from Marc Zyngier's message of June 24, 2021 8:06 pm:
> On Thu, 24 Jun 2021 09:58:00 +0100,
> Nicholas Piggin wrote:
>>
>> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
>> > From: David Stevens
>> > out_unlock:
>> >if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->ro
On Thu, 24 Jun 2021 04:57:47 +0100,
David Stevens wrote:
>
> From: David Stevens
>
> Avoid converting pfns returned by follow_fault_pfn to struct pages to
> transiently take a reference. The reference was originally taken to
> match the reference taken by gup. However, pfns returned by
> follow
Excerpts from Paolo Bonzini's message of June 24, 2021 8:21 pm:
> On 24/06/21 12:17, Nicholas Piggin wrote:
>>> If all callers were updated that is one thing, but from the changelog
>>> it sounds like that would not happen and there would be some gfn_to_pfn
>>> users left over.
>>>
>>> But yes in t
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
> follow_pte in gfn_to_pfn. However, the resolved pfns may not have
> assoicated struct pages, so they should not be passed to pfn_to_page.
> This series removes
Hi Aneesh,
A little bit of wordsmithing below...
Le 17/06/2021 à 18:51, Aneesh Kumar K.V a écrit :
PAPR interface currently supports two different ways of communicating resource
grouping details to the OS. These are referred to as Form 0 and Form 1
associativity grouping. Form 0 is the older fo
On 24/06/21 12:17, Nicholas Piggin wrote:
If all callers were updated that is one thing, but from the changelog
it sounds like that would not happen and there would be some gfn_to_pfn
users left over.
But yes in the end you would either need to make gfn_to_pfn never return
a page found via follo
Excerpts from Nicholas Piggin's message of June 24, 2021 7:57 pm:
> Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm:
>> On 24/06/21 10:52, Nicholas Piggin wrote:
For now, wrap all calls to gfn_to_pfn functions in the new helper
function. Callers which don't need the page st
On 24/06/21 12:06, Marc Zyngier wrote:
On Thu, 24 Jun 2021 09:58:00 +0100,
Nicholas Piggin wrote:
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
From: David Stevens
out_unlock:
if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa))
read_unlock(&v
On 24/06/21 11:57, Nicholas Piggin wrote:
Needing kvm_pfn_page_unwrap is a sign that something might be buggy, so
it's a good idea to move the short name to the common case and the ugly
kvm_pfn_page_unwrap(gfn_to_pfn(...)) for the weird one. In fact I'm not
sure there should be any kvm_pfn_page_
On Thu, 24 Jun 2021 09:58:00 +0100,
Nicholas Piggin wrote:
>
> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> > From: David Stevens
> > out_unlock:
> > if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa))
> > read_unlock(&vcpu->kvm->mmu_lock);
> > els
Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm:
> On 24/06/21 10:52, Nicholas Piggin wrote:
>>> For now, wrap all calls to gfn_to_pfn functions in the new helper
>>> function. Callers which don't need the page struct will be updated in
>>> follow-up patches.
>> Hmm. You mean callers
On 24/06/21 10:43, Nicholas Piggin wrote:
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
From: David Stevens
Changelog? This looks like a bug, should it have a Fixes: tag?
Probably has been there forever... The best way to fix the bug would be
to nuke mmu_audit.c, which I'
On 24/06/21 10:52, Nicholas Piggin wrote:
For now, wrap all calls to gfn_to_pfn functions in the new helper
function. Callers which don't need the page struct will be updated in
follow-up patches.
Hmm. You mean callers that do need the page will be updated? Normally
if there will be leftover use
Hi David,
On Thu, 24 Jun 2021 04:57:45 +0100,
David Stevens wrote:
>
> From: David Stevens
>
> Return a struct kvm_pfn_page containing both a pfn and an optional
> struct page from the gfn_to_pfn family of functions. This differentiates
> the gup and follow_fault_pfn cases, which allows caller
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> From: David Stevens
> out_unlock:
> if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa))
> read_unlock(&vcpu->kvm->mmu_lock);
> else
> write_unlock(&vcpu->kvm->mmu_lock);
> - kvm_rel
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> From: David Stevens
>
> Return a struct kvm_pfn_page containing both a pfn and an optional
> struct page from the gfn_to_pfn family of functions. This differentiates
> the gup and follow_fault_pfn cases, which allows callers that o
Le 22/06/2021 à 15:39, Daniel Henrique Barboza a écrit :
The validation done at the start of dlpar_memory_add_by_ic() is an all
of nothing scenario - if any LMBs in the range is marked as RESERVED we
can fail right away.
We then can remove the 'lmbs_available' var and its check with
'lmbs_to_add
Le 22/06/2021 à 15:39, Daniel Henrique Barboza a écrit :
After a successful dlpar_add_lmb() call the LMB is marked as reserved.
Later on, depending whether we added enough LMBs or not, we rely on
the marked LMBs to see which ones might need to be removed, and we
remove the reservation of all of t
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> From: David Stevens
Changelog? This looks like a bug, should it have a Fixes: tag?
Thanks,
Nick
>
> Signed-off-by: David Stevens
> ---
> arch/x86/kvm/mmu/mmu_audit.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/
Le 22/06/2021 à 15:39, Daniel Henrique Barboza a écrit :
The function is counting reserved LMBs as available to be added, but
they aren't. This will cause the function to miscalculate the available
LMBs and can trigger errors later on when executing dlpar_add_lmb().
Indeed I'm wondering if dlpa
David Gibson writes:
> On Thu, Jun 17, 2021 at 10:21:05PM +0530, Aneesh Kumar K.V wrote:
>> PAPR interface currently supports two different ways of communicating
>> resource
>> grouping details to the OS. These are referred to as Form 0 and Form 1
>> associativity grouping. Form 0 is the older f
Persistent memory devices like NVDIMMs can loose cached writes in case
something prevents flush on power-fail. Such situations are termed as
dirty shutdown and are exposed to applications as
last-shutdown-state (LSS) flag and a dirty-shutdown-counter(DSC) as
described at [1]. The latter being usefu
Stephen Rothwell writes:
> Hi all,
>
> Commit
>
> 77bbbc0cf848 ("KVM: PPC: Book3S HV: Fix TLB management on SMT8 POWER9 and
> POWER10 processors")
>
> is missing a Signed-off-by from its author.
That was actually deliberate.
Suraj wrote the patch when he was at IBM, but never sent it.
Paul &
On Wed, Jun 16, 2021 at 01:34:59PM -0700, Kees Cook wrote:
> Fix typo in memcpy() where size should be CTR_RFC3686_NONCE_SIZE.
>
> Fixes: 030f4e968741 ("crypto: nx - Fix reentrancy bugs")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Kees Cook
> ---
> drivers/crypto/nx/nx-aes-ctr.c | 2 +-
> 1 f
On 24/06/21 05:57, David Stevens wrote:
static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
- int map_writable, int max_level, kvm_pfn_t pfn,
+ int map_writable, int max_level,
+ const struct kvm_pfn_page *p
97 matches
Mail list logo
