Hi Michael Bringmann,
On 12/13/18 10:42 PM, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Non-overlay dynamic devicetree node removal may leave the node in
> the phandle cache. Subsequent calls to of_find_node_by_phandle()
> will incorrectly find the stale entry. This bug exposed the
From: Frank Rowand
Non-overlay dynamic devicetree node removal may leave the node in
the phandle cache. Subsequent calls to of_find_node_by_phandle()
will incorrectly find the stale entry. Remove the node from the
cache.
Add paranoia checks in of_find_node_by_phandle() as a second level
of def
From: Frank Rowand
The phandle cache contains struct device_node pointers. The refcount
of the pointers was not incremented while in the cache, allowing use
after free error after kfree() of the node. Add the proper increment
and decrement of the use count.
Fixes: 0b3ce78e90fc ("of: cache phan
From: Frank Rowand
Non-overlay dynamic devicetree node removal may leave the node in
the phandle cache. Subsequent calls to of_find_node_by_phandle()
will incorrectly find the stale entry. This bug exposed the foloowing
phandle cache refcount bug.
The refcount of phandle_cache entries is not i
Christophe Leroy writes:
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index fe758cedb93f..d8e56e03c9c6 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -749,7 +749,11 @@ void __init early_init_devtree(void *params)
> memblock_allo
Hello,
I was booting next-20181213 in qemu with lockdep enabled and saw this:
spin_lock-torture:--- Start of test [debug]: nwriters_stress=2
nreaders_stress=0 stat_interval=60 verbose=1 shuffle_interval=3
stutter=5 shutdown_secs=0 onoff_interval=0 onoff_holdoff=0
spin_lock-torture: Creating
Previously when a device was being emulated by an L1 guest for an L2
guest, that device couldn't then be passed through to an L3 guest. This
was because the L1 guest had no method for accessing L3 memory.
The hcall H_COPY_TOFROM_GUEST provides this access. Thus this setup for
passthrough can now b
A guest cannot access quadrants 1 or 2 as this would result in an
exception. Thus introduce the hcall H_COPY_TOFROM_GUEST to be used by a
guest when it wants to perform an access to quadrants 1 or 2, for
example when it wants to access memory for one of its nested guests.
Also provide an implement
Allow for a device which is being emulated at L0 (the host) for an L1
guest to be passed through to a nested (L2) guest.
The existing kvmppc_hv_emulate_mmio function can be used here. The main
challenge is that for a load the result must be stored into the L2 gpr,
not an L1 gpr as would normally b
The functions kvmppc_st and kvmppc_ld are used to access guest memory
from the host using a guest effective address. They do so by translating
through the process table to obtain a guest real address and then using
kvm_read_guest or kvm_write_guest to make the access with the guest real
address.
T
The kvmppc_ops struct is used to store function pointers to kvm
implementation specific functions.
Introduce two new functions load_from_eaddr and store_to_eaddr to be
used to load from and store to a guest effective address respectively.
Also implement these for the kvm-hv module. If we are usin
The POWER9 radix mmu has the concept of quadrants. The quadrant number
is the two high bits of the effective address and determines the fully
qualified address to be used for the translation. The fully qualified
address consists of the effective lpid, the effective pid and the
effective address. Th
There exists a function kvm_is_radix() which is used to determine if a
kvm instance is using the radix mmu. However this only applies to the
first level (L1) guest. Add a function kvmhv_vcpu_is_radix() which can
be used to determine if the current execution context of the vcpu is
radix, accounting
The kvm capability KVM_CAP_SPAPR_TCE_VFIO is used to indicate the
availability of in kernel tce acceleration for vfio. However it is
currently the case that this is only available on a powernv machine,
not for a pseries machine.
Thus make this capability dependent on having the cpu feature
CPU_FTR
This patch series allows for emulated devices to be passed through to nested
guests, irrespective of at which level the device is being emulated.
Note that the emulated device must be using dma, not virtio.
For example, passing through an emulated e1000:
1. Emulate the device at L(n) for L(n+1)
On Thu, Dec 13, 2018 at 05:17:17PM +1100, Alexey Kardashevskiy wrote:
> This new memory does not have page structs as it is not plugged to
> the host so gup() will fail anyway.
>
> This adds 2 helpers:
> - mm_iommu_newdev() to preregister the "memory device" memory so
> the rest of API can still b
Previously when a device was being emulated by an L1 guest for an L2
guest, that device couldn't then be passed through to an L3 guest. This
was because the L1 guest had no method for accessing L3 memory.
The hcall H_COPY_TOFROM_GUEST provides this access. Thus this setup for
passthrough can now b
A guest cannot access quadrants 1 or 2 as this would result in an
exception. Thus introduce the hcall H_COPY_TOFROM_GUEST to be used by a
guest when it wants to perform an access to quadrants 1 or 2, for
example when it wants to access memory for one of its nested guests.
Also provide an implement
Allow for a device which is being emulated at L0 (the host) for an L1
guest to be passed through to a nested (L2) guest.
The existing kvmppc_hv_emulate_mmio function can be used here. The main
challenge is that for a load the result must be stored into the L2 gpr,
not an L1 gpr as would normally b
The functions kvmppc_st and kvmppc_ld are used to access guest memory
from the host using a guest effective address. They do so by translating
through the process table to obtain a guest real address and then using
kvm_read_guest or kvm_write_guest to make the access with the guest real
address.
T
The kvmppc_ops struct is used to store function pointers to kvm
implementation specific functions.
Introduce two new functions load_from_eaddr and store_to_eaddr to be
used to load from and store to a guest effective address respectively.
Also implement these for the kvm-hv module. If we are usin
The POWER9 radix mmu has the concept of quadrants. The quadrant number
is the two high bits of the effective address and determines the fully
qualified address to be used for the translation. The fully qualified
address consists of the effective lpid, the effective pid and the
effective address. Th
There exists a function kvm_is_radix() which is used to determine if a
kvm instance is using the radix mmu. However this only applies to the
first level (L1) guest. Add a function kvmhv_vcpu_is_radix() which can
be used to determine if the current execution context of the vcpu is
radix, accounting
The kvm capability KVM_CAP_SPAPR_TCE_VFIO is used to indicate the
availability of in kernel tce acceleration for vfio. However it is
currently the case that this is only available on a powernv machine,
not for a pseries machine.
Thus make this capability dependent on having the cpu feature
CPU_FTR
This patch series allows for emulated devices to be passed through to nested
guests, irrespective of at which level the device is being emulated.
Note that the emulated device must be using dma, not virtio.
For example, passing through an emulated e1000:
1. Emulate the device at L(n) for L(n+1)
On Thu, 2018-12-13 at 16:24 +1100, Paul Mackerras wrote:
> On Mon, Dec 10, 2018 at 02:58:24PM +1100, Suraj Jitindar Singh wrote:
> > A guest cannot access quadrants 1 or 2 as this would result in an
> > exception. Thus introduce the hcall H_COPY_TOFROM_GUEST to be used
> > by a
> > guest when it wa
Hi Christophe,
You know it's the trivial patches that are going to get lots of review
comments :)
Christophe Leroy writes:
> As several other arches including x86, this patch makes it explicit
> that a bad page fault is a NULL pointer dereference when the fault
> address is lower than PAGE_SIZE
Hi Naveen,
"Naveen N. Rao" writes:
> Hi Michael,
>
> Naveen N. Rao wrote:
>> Add debugfs interface to retrieve associativity information for lpar
>> vcpus (debugfs/vphn/lpar) and the hypervisor cpus (debugfs/vphn/hyp).
>> This information is useful to derive various metrics, including the vcpu
>>
The dma_direct_supported() function intends to check the DMA mask against
specific values. However, the phys_to_dma() function includes the SME
encryption mask, which defeats the intended purpose of the check. This
results in drivers that support less than 48-bit DMA (SME encryption mask
is bit 47)
On 13 December 2018 at 6:48PM, Christian Zigotzky wrote:
On 13 December 2018 at 2:34PM, Christian Zigotzky wrote:
On 13 December 2018 at 12:25PM, Christoph Hellwig wrote:
On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
I tried it again but I get the following error message:
This argument is required to extend the generic ptrace API with
PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going
to be called from ptrace_request() along with syscall_get_nr(),
syscall_get_arguments(), syscall_get_error(), and
syscall_get_return_value() functions with a tracee as their
PTRACE_GET_SYSCALL_INFO is a generic ptrace API that lets ptracer obtain
details of the syscall the tracee is blocked in.
There are two reasons for a special syscall-related ptrace request.
Firstly, with the current ptrace API there are cases when ptracer cannot
retrieve necessary information abo
On Thu, Dec 13, 2018 at 07:45:57PM +, Lendacky, Thomas wrote:
> So I think this needs to be __phys_to_dma() here. I only recently got a
> system that had a device where the driver only supported 32-bit DMA and
> found that when SME is active this returns 0 and causes the driver to fail
> to ini
On 10/04/2018 10:13 AM, Alexander Duyck wrote:
> On Thu, Oct 4, 2018 at 4:25 AM Robin Murphy wrote:
>>
>> On 04/10/18 00:48, Alexander Duyck wrote:
>>> It appears that in commit 9d7a224b463e ("dma-direct: always allow dma mask
>>> <= physiscal memory size") the logic of the test was changed from a
Implement pcibios_sriov_{add|del}_vfs as empty functions. VF
creation will be triggered by the hotplug code.
Signed-off-by: Sebastian Ott
---
arch/s390/pci/pci.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 9f6f392a4461..b5f8db6
Move VF detection and device creation code to weak functions
such that architectures can provide a different implementation.
Signed-off-by: Sebastian Ott
---
drivers/pci/iov.c | 43 +++
include/linux/pci.h | 2 ++
2 files changed, 33 insertions(+), 12 d
On 13 December 2018 at 2:34PM, Christian Zigotzky wrote:
On 13 December 2018 at 12:25PM, Christoph Hellwig wrote:
On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
I tried it again but I get the following error message:
MODPOST vmlinux.o
arch/powerpc/kernel/dma-iommu.o: In fu
From: Elvira Khabirova
Arch code should use tracehook_*() helpers, as documented in
include/linux/tracehook.h, ptrace_report_syscall() is not expected to
be used outside that file.
The patch does not look very nice, but at least it is correct
and opens the way for PTRACE_GET_SYSCALL_INFO API.
C
syscall_get_error() is required to be implemented on this
architecture in addition to already implemented syscall_get_nr(),
syscall_get_arguments(), syscall_get_return_value(), and
syscall_get_arch() functions in order to extend the generic
ptrace API with PTRACE_GET_SYSCALL_INFO request.
Cc: Mich
Hi Again,
Le 13/12/2018 à 13:16, Christophe Leroy a écrit :
Hi,
On 12/03/2018 09:55 PM, Jonathan Neuschäfer wrote:
Hi,
On Thu, Nov 29, 2018 at 07:00:16PM +, Christophe Leroy wrote:
This patch reworks mmu_mapin_ram() to be more generic and map as much
blocks as possible. It now supports b
This patch fixes early DEBUG messages in prom.c:
- Use %px instead of %p to see the addresses
- Use %x instead of %llx when phys_addr_t is not 64 bits.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/prom.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/
On 13 December 2018 at 12:25PM, Christoph Hellwig wrote:
On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
I tried it again but I get the following error message:
MODPOST vmlinux.o
arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask':
(.text+0x274): unde
Hi,
On 12/03/2018 09:55 PM, Jonathan Neuschäfer wrote:
Hi,
On Thu, Nov 29, 2018 at 07:00:16PM +, Christophe Leroy wrote:
This patch reworks mmu_mapin_ram() to be more generic and map as much
blocks as possible. It now supports blocks not starting at address 0.
It scans DBATs array to find
On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote:
> I tried it again but I get the following error message:
>
> MODPOST vmlinux.o
> arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask':
> (.text+0x274): undefined reference to `.dma_direct_get_required_mask'
On 13 December 2018 at 10:47AM, Christian Zigotzky wrote:
On 13 December 2018 at 10:10AM, Christoph Hellwig wrote:
On Thu, Dec 13, 2018 at 09:41:50AM +0100, Christian Zigotzky wrote:
Today I tried the first patch (0001-get_required_mask.patch) with
the last
good commit (977706f9755d2d697aa6f45b
Hi Michael,
Naveen N. Rao wrote:
Add debugfs interface to retrieve associativity information for lpar
vcpus (debugfs/vphn/lpar) and the hypervisor cpus (debugfs/vphn/hyp).
This information is useful to derive various metrics, including the vcpu
dispatch statistics in a SPLPAR environment.
Any
On 13 December 2018 at 10:10AM, Christoph Hellwig wrote:
On Thu, Dec 13, 2018 at 09:41:50AM +0100, Christian Zigotzky wrote:
Today I tried the first patch (0001-get_required_mask.patch) with the last
good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). Unfortunately this
patch is already incl
On Thu, Dec 13, 2018 at 09:41:50AM +0100, Christian Zigotzky wrote:
> Today I tried the first patch (0001-get_required_mask.patch) with the last
> good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). Unfortunately this
> patch is already included in the last good commit
> (977706f9755d2d697aa
System call table generation script must be run to gener-
ate unistd_32/64.h and syscall_table_32/64/c32/spu.h files.
This patch will have changes which will invokes the script.
This patch will generate unistd_32/64.h and syscall_table-
_32/64/c32/spu.h files by the syscall table generation
script
PowerPC uses a syscall table with native and compat calls
interleaved, which is a slightly simpler way to define two
matching tables.
As we move to having the tables generated, that advantage
is no longer important, but the interleaved table gets in
the way of using the same scripts as on the othe
The system call tables are in different format in all
architecture and it will be difficult to manually add or
modify the system calls in the respective files. To make
it easy by keeping a script and which will generate the
uapi header and syscall table file. This change will also
help to unify the
Move the macro definition for compat_sys_sigsuspend from
asm/systbl.h to the file which it is getting included.
One of the patch in this patch series is generating uapi
header and syscall table files. In order to come up with
a common implimentation across all architecture, we need
to do this chan
NR_syscalls macro holds the number of system call exist
in powerpc architecture. We have to change the value of
NR_syscalls, if we add or delete a system call.
One of the patch in this patch series has a script which
will generate a uapi header based on syscall.tbl file.
The syscall.tbl file conta
The purpose of this patch series is, we can easily
add/modify/delete system call table support by cha-
nging entry in syscall.tbl file instead of manually
changing many files. The other goal is to unify the
system call table generation support implementation
across all the architectures.
The sy
On 12 December 2018 at 3:39PM, Christian Zigotzky wrote:
Hi Christoph,
Thanks a lot for your reply. I will test your patches tomorrow.
Cheers,
Christian
Sent from my iPhone
On 12. Dec 2018, at 15:15, Christoph Hellwig wrote:
Thanks for bisecting. I've spent some time going over the conver
Le 12/12/2018 à 14:05, Michael Ellerman a écrit :
Christophe Leroy writes:
When disassembling InstructionTLBError we get the following messy code:
c000138c: 7d 84 63 78 mr r4,r12
c0001390: 75 25 58 00 andis. r5,r9,22528
c0001394: 75 2a 40 00 andis. r10,
When disassembling InstructionTLBError we get the following messy code:
c000138c: 7d 84 63 78 mr r4,r12
c0001390: 75 25 58 00 andis. r5,r9,22528
c0001394: 75 2a 40 00 andis. r10,r9,16384
c0001398: 41 a2 00 08 beq c00013a0
c000139c: 7c 00 22
57 matches
Mail list logo
