Use a CONSOLE_LOGLEVEL_DEBUG macro for console_loglevel rather
than a naked number.
Signed-off-by: Sergey Senozhatsky
---
arch/powerpc/kernel/udbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index 7cc38b5b58bc..8db
hi Christophe,
On 1/3/19 3:19 PM, LEROY Christophe wrote:
> Breno Leitao a écrit :
>
>> This patch simply adds definitions for the MSR bits and some macros to
>> test for MSR TM bits.
>>
>> This was copied from arch/powerpc/include/asm/reg.h generic MSR part.
>
> Can't we find a way to avoid du
Hi Breno,
Le 07/01/2019 à 13:44, Breno Leitao a écrit :
hi Christophe,
On 1/3/19 3:19 PM, LEROY Christophe wrote:
Breno Leitao a écrit :
This patch simply adds definitions for the MSR bits and some macros to
test for MSR TM bits.
This was copied from arch/powerpc/include/asm/reg.h generic
hi Christophe,
On 1/7/19 10:47 AM, Christophe Leroy wrote:
> Hi Breno,
>
> Le 07/01/2019 à 13:44, Breno Leitao a écrit :
>> hi Christophe,
>>
>> On 1/3/19 3:19 PM, LEROY Christophe wrote:
>>> Breno Leitao a écrit :
>>>
This patch simply adds definitions for the MSR bits and some macros to
>
On 04/01/19 17:30, Sean Christopherson wrote:
>> +
>> +if (kvm_available_flush_tlb_with_range()
>> +&& (tmp_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH)) {
>> +struct kvm_mmu_page *leaf_sp = page_header(sp->spt[i]
>> +
On 04/01/19 16:50, Sean Christopherson wrote:
> Tangentially related, does mmu_lock actually need to be held while we
> walk dirty_bitmap in kvm_{clear,get}_dirty_log_protect()? The bitmap
> itself is protected by slots_lock (a lockdep assertion would be nice
> too), e.g. can we grab the lock iff
On 04/01/19 09:54, lantianyu1...@gmail.com wrote:
> rmap_head = __gfn_to_rmap(slot->base_gfn + gfn_offset +
> __ffs(mask),
> PT_PAGE_TABLE_LEVEL, slot);
> - __rmap_write_protect(kvm, rmap_head, false);
> + flush |= __rma
Update design.txt to reflect the presence of the exclude_host
and exclude_guest perf flags.
Signed-off-by: Andrew Murray
---
tools/perf/design.txt | 4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/design.txt b/tools/perf/design.txt
index a28dca2..0453ba2 100644
--- a/tools/perf/
Many PMU drivers do not have the capability to exclude counting events
that occur in specific contexts such as idle, kernel, guest, etc. These
drivers indicate this by returning an error in their event_init upon
testing the events attribute flags.
However this approach requires that each time a ne
Add a function that tests if any of the perf event exclusion flags
are set on a given event.
Signed-off-by: Andrew Murray
---
include/linux/perf_event.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 1d5c551..54a78d2 100
Many PMU drivers do not have the capability to exclude counting events
that occur in specific contexts such as idle, kernel, guest, etc. These
drivers indicate this by returning an error in their event_init upon
testing the events attribute flags. This approach is error prone and
often inconsistent
As the Alpha PMU doesn't support context exclusion let's advertise
the PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that __hw_per
The ARM PMU driver can be used to represent a variety of ARM based
PMUs. Some of these PMUs do not provide support for context
exclusion, where this is the case we advertise the
PERF_PMU_CAP_NO_EXCLUDE capability to ensure that perf prevents us
from handling events where any exclusion flags are set
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
Signed-off-by: Andrew Murray
Ac
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
Signed-off-by: Andrew Murray
Ac
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that qcom_{l2|
For PowerPC PMUs that do not support context exclusion let's
advertise the PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that
perf will prevent us from handling events where any exclusion flags
are set. Let's also remove the now unnecessary check for exclusion
flags.
Signed-off-by: Andrew Murra
For drivers that do not support context exclusion let's advertise the
PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
Signed-off-by: Andrew Murray
---
For x86 PMUs that do not support context exclusion let's advertise the
PERF_PMU_CAP_NO_EXCLUDE capability. This ensures that perf will
prevent us from handling events where any exclusion flags are set.
Let's also remove the now unnecessary check for exclusion flags.
This change means that amd/iomm
Now that perf_flags is not used we remove it.
Signed-off-by: Andrew Murray
---
include/uapi/linux/perf_event.h | 2 --
tools/include/uapi/linux/perf_event.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 9de8780
The Cavium ThunderX2 UNCORE PMU driver doesn't support any event
filtering. Let's advertise the PERF_PMU_CAP_NO_EXCLUDE capability to
simplify the code.
Signed-off-by: Andrew Murray
---
drivers/perf/thunderx2_pmu.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/dri
On 04/01/19 09:53, lantianyu1...@gmail.com wrote:
> @@ -332,6 +332,7 @@ struct kvm_mmu_page {
> int root_count; /* Currently serving as active root */
> unsigned int unsync_children;
> struct kvm_rmap_head parent_ptes; /* rmap pointers to parent sptes */
> + u64 *spte
On 04/01/19 09:53, lantianyu1...@gmail.com wrote:
> struct kvm_mmu_page {
> struct list_head link;
> +
> + /*
> + * Tlb flush with range list uses struct kvm_mmu_page as list entry
> + * and all list operations should be under protection of mmu_lock.
> + */
> + struct
Le 04/01/2019 à 16:24, Horia Geanta a écrit :
On 1/4/2019 5:17 PM, Horia Geanta wrote:
On 12/21/2018 10:07 AM, Christophe Leroy wrote:
[snip]
IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
cannot be DMA mapped anymore.
This looks better, thanks.
This patch copi
The XIVE native exploitation mode specs define a set of Hypervisor
calls to configure the sources and the event queues :
- H_INT_GET_SOURCE_INFO
used to obtain the address of the MMIO page of the Event State
Buffer (PQ bits) entry associated with the source.
- H_INT_SET_SOURCE_CONFIG
This will let the guest create a memory mapping to expose the ESB MMIO
regions used to control the interrupt sources, to trigger events, to
EOI or to turn off the sources.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/uapi/asm/kvm.h | 4 ++
arch/powerpc/kvm/book3s_xive_native.c | 9
The guest physical address of the event queue will be part of the
state to transfer in the migration. Cache its value when the queue is
configured, it will save us an OPAL call.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/xive.h | 2 ++
arch/powerpc/kvm/book3s_xive_native.
We will have different KVM devices for interrupts, one for the
XICS-over-XIVE mode and one for the XIVE native exploitation
mode. Let's add some checks to make sure we are not mixing the
interfaces in KVM.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s_xive.c | 6 ++
1 file chan
These flags are shared between Linux/KVM implementing the hypervisor
calls for the XIVE native exploitation mode and the driver for the
sPAPR guests.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/xive.h | 23 +++
arch/powerpc/sysdev/xive/spapr.c | 28 -
When the VM is stopped in a migration sequence, the sources are masked
and the XIVE IC is synced to stabilize the EQs. When done, the KVM
ioctl KVM_DEV_XIVE_SAVE_EQ_PAGES is called to mark dirty the EQ pages.
The migration can then transfer the remaining dirty pages to the
destination and start co
Hello,
On the POWER9 processor, the XIVE interrupt controller can control
interrupt sources using MMIO to trigger events, to EOI or to turn off
the sources. Priority management and interrupt acknowledgment is also
controlled by MMIO in the CPU presenter subengine.
PowerNV/baremetal Linux runs nat
This is the basic framework for the new KVM device supporting the XIVE
native exploitation mode. The user interface exposes a new capability
and a new KVM device to be used by QEMU.
Internally, the interface to the new KVM device is protected with a
new interrupt mode: KVMPPC_IRQ_XIVE.
Signed-off
Theses are use to capure the XIVE EAS table of the KVM device, the
configuration of the source targets.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/uapi/asm/kvm.h | 11
arch/powerpc/kvm/book3s_xive_native.c | 87 +++
2 files changed, 98 insertions(+)
The KVM device for the XIVE native exploitation mode will reuse the
structures of the XICS-over-XIVE glue implementation. Some code will
also be shared : source block creation and destruction, target
selection and escalation attachment.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s
Clear the ESB pages from the VMA of the IRQ being pass through to the
guest and let the fault handler repopulate the VMA when the ESB pages
are accessed for an EOI or for a trigger.
Storing the VMA under the KVM XIVE device is a little ugly.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/
At a VCPU level, the state of the thread context interrupt management
registers needs to be collected. These registers are cached under the
'xive_saved_state.w01' field of the VCPU when the VPCU context is
pulled from the HW thread. An OPAL call retrieves the backup of the
IPB register in the NVT s
This will be used to destroy the KVM XICS or XIVE device when the
sPAPR machine is reseted. When the VM boots, the CAS negotiation
process will determine which interrupt mode to use and the appropriate
KVM device will then be created.
Signed-off-by: Cédric Le Goater
---
include/linux/kvm_host.h
The support for XIVE native exploitation mode in Linux/KVM needs a
couple more OPAL calls to configure the sPAPR guest and to get/set the
state of the XIVE internal structures.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/opal-api.h | 11 ++-
arch/powerpc/include/asm/op
This will let the guest create a memory mapping to expose the XIVE
MMIO region (TIMA) used for interrupt management at the CPU level.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/asm/xive.h | 1 +
arch/powerpc/include/uapi/asm/kvm.h | 1 +
arch/powerpc/kvm/book3s_xive_nativ
Interrupt sources are simply created at the OPAL level and then
MASKED. KVM only needs to know about their type: LSI or MSI.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/uapi/asm/kvm.h | 5 +
arch/powerpc/kvm/book3s_xive_native.c | 98 +++
.../power
The ESB MMIO region controls the interrupt sources of the guest. QEMU
will query an fd (GET_ESB_FD ioctl) and map this region at a specific
address for the guest to use. The guest will obtain this information
using the H_INT_GET_SOURCE_INFO hcall. To inform KVM of the address
setting used by QEMU,
The Effective IRQ Source Number is the interrupt number pushed in the
event queue that the guest OS will use to dispatch events internally.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/kvm/book3s_xive.h | 3 +++
arch/powerpc/kvm/book3s_xive.c | 1 +
2 files changed, 4 insertions(+)
diff --g
When migration of a VM is initiated, a first copy of the RAM is
transferred to the destination before the VM is stopped. At that time,
QEMU needs to perform a XIVE quiesce sequence to stop the flow of
event notifications and stabilize the EQs. The sources are masked and
the XIVE IC is synced with t
These are used to capture the XIVE END table of the KVM device. It
relies on an OPAL call to retrieve from the XIVE IC the EQ toggle bit
and index which are updated by the HW when events are enqueued in the
guest RAM.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/include/uapi/asm/kvm.h | 2
Add the PCIE EP node in dts for ls1046a.
Signed-off-by: Xiaowei Bao
---
v2:
- Add the SoC specific compatibles.
v3:
- no change
v4:
- no change
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 34 +++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arc
Add the documentation for the Device Tree binding for the layerscape PCIe
controller with EP mode.
Signed-off-by: Xiaowei Bao
---
v2:
- Add the SoC specific compatibles.
v3:
- modify the commit message.
v4:
- no change.
.../devicetree/bindings/pci/layerscape-pci.txt |3 +++
1 files c
Add the layerscape EP device support in pci_endpoint_test driver.
Signed-off-by: Xiaowei Bao
---
v2:
- no change
v3:
- no change
v4:
- delate the comments.
drivers/misc/pci_endpoint_test.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/pci_endpoint_test
Add the PCIe EP mode support for layerscape platform.
Signed-off-by: Xiaowei Bao
---
v2:
- remove the EP mode check function.
v3:
- modif the return value when enter default case.
v4:
- no change.
drivers/pci/controller/dwc/Makefile|2 +-
drivers/pci/controller/dwc/pci-layers
On Sun, Jan 06, 2019 at 09:43:46AM +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2019-01-05 at 10:51 -0700, Jason Gunthorpe wrote:
> >
> > > Interesting. I've investigated this further, though I don't have as
> > > many new clues as I'd like. The problem occurs reliably, at least on
> > > one p
ppc64 use CMA area for the allocation of guest page table (hash page table). We
won't
be able to start guest if we fail to allocate hash page table. We have observed
hash table allocation failure because we failed to migrate pages out of CMA
region
because they were pinned. This happen when we ar
This patch add PF_MEMALLOC_NOCMA which make sure any allocation in that context
is marked non movable and hence cannot be satisfied by CMA region.
This is useful with get_user_pages_cma_migrate where we take a page pin by
migrating pages from CMA region. Marking the section PF_MEMALLOC_NOCMA ensur
This helper does a get_user_pages_fast making sure we migrate pages found in the
CMA area before taking page reference. This makes sure that we don't keep
non-movable pages (due to page reference count) in the CMA area.
This will be used by ppc64 in a later patch to avoid pinning pages in the CMA
Current code doesn't do page migration if the page allocated is a compound page.
With HugeTLB migration support, we can end up allocating hugetlb pages from
CMA region. Also THP pages can be allocated from CMA region. This patch updates
the code to handle compound pages correctly.
This use the new
THP pages can get split during different code paths. An incremented reference
count do imply we will not split the compound page. But the pmd entry can be
converted to level 4 pte entries. Keep the code simpler by allowing large
IOMMU page size only if the guest ram is backed by hugetlb pages.
Sig
On Fri, Dec 21, 2018 at 08:07:52AM +, Christophe Leroy wrote:
> [2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
> dma_nommu_map_page+0x44/0xd4
> [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
> 4.20.0-rc5-00560-g6bfb52e23a00-dirty
The series is aimed at adding y2038-safe timeout options:
SO_RCVTIMEO_NEW and SO_SNDTIMEO_NEW.
This is similar to the previous series adding y2038-safe
SO_TIMESTAMP* options.
The series needs to be applied after the socket timestamp series:
https://lore.kernel.org/lkml/20190108032657.8331-1-deepa
SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
as the time format. struct timeval is not y2038 safe.
The subsequent patches in the series add support for new socket
timeout options with _NEW suffix that are y2038 safe.
Rename the existing options with _OLD suffix forms so that the
ri
Add new socket timeout options that are y2038 safe.
Signed-off-by: Deepa Dinamani
Cc: ccaul...@redhat.com
Cc: da...@davemloft.net
Cc: del...@gmx.de
Cc: pau...@samba.org
Cc: r...@linux-mips.org
Cc: r...@twiddle.net
Cc: cluster-de...@redhat.com
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-al...@vger
On Mon, Jan 07, 2019 at 09:01:29PM -0700, Jason Gunthorpe wrote:
> On Sun, Jan 06, 2019 at 09:43:46AM +1100, Benjamin Herrenschmidt wrote:
> > On Sat, 2019-01-05 at 10:51 -0700, Jason Gunthorpe wrote:
> > >
> > > > Interesting. I've investigated this further, though I don't have as
> > > > many ne
[2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
dma_nommu_map_page+0x44/0xd4
[2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
[2.384740] NIP: c000c540 LR: c000c584 CTR:
[2.38974
This patch moves the mapping of IV after the kmalloc(). This
avoids having to unmap in case kmalloc() fails.
Signed-off-by: Christophe Leroy
---
new in v4
drivers/crypto/talitos.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/tali
Andrew Morton writes:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Fri, 04 Jan 2019 22:49:52 + bugzilla-dae...@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=202149
>>
>> Bug ID: 202149
In powerpc code, there are several places implementing safe
access to user data. This is sometimes implemented using
probe_kernel_address() with additional access_ok() verification,
sometimes with get_user() enclosed in a pagefault_disable()/enable()
pair, etc. :
show_user_instructions()
ba
Instead of opencoding, use probe_user_read() to failessly
read a user location.
Signed-off-by: Christophe Leroy
---
v2: Using probe_user_read() instead of probe_user_address()
arch/powerpc/kernel/process.c | 12 +---
arch/powerpc/mm/fault.c | 6 +-
arch/powerpc/perf/call
On Tue, Jan 08, 2019 at 07:37:44AM +, Christophe Leroy wrote:
> In powerpc code, there are several places implementing safe
> access to user data. This is sometimes implemented using
> probe_kernel_address() with additional access_ok() verification,
> sometimes with get_user() enclosed in a pag
65 matches
Mail list logo
