* Re: [PATCH v2 05/16] KVM: PPC: Book3S HV: XIVE: add a control to configure a source
From: David Gibson @ 2019-02-25 2:21 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190222112840.25000-6-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 9807 bytes --]
On Fri, Feb 22, 2019 at 12:28:29PM +0100, Cédric Le Goater wrote:
> This control will be used by the H_INT_SET_SOURCE_CONFIG hcall from
> QEMU and also to restore the configuration of the source in the KVM
> device.
>
> The XIVE internal IRQ structure is extended with the value of the
> Effective Interrupt Source Number. The EISN is the interrupt number
> pushed in the event queue that the guest OS will use to dispatch
> events internally. Caching the EISN value in KVM ease the test when
> checking if a reconfiguration is indeed needed.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> arch/powerpc/include/uapi/asm/kvm.h | 11 +++
> arch/powerpc/kvm/book3s_xive.h | 4 +
> arch/powerpc/kvm/book3s_xive.c | 5 +-
> arch/powerpc/kvm/book3s_xive_native.c | 97 ++++++++++++++++++++++
> Documentation/virtual/kvm/devices/xive.txt | 20 +++++
> 5 files changed, 135 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index a9ad99f2a11b..91899c7f9abd 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -678,9 +678,20 @@ struct kvm_ppc_cpu_char {
> /* POWER9 XIVE Native Interrupt Controller */
> #define KVM_DEV_XIVE_GRP_CTRL 1
> #define KVM_DEV_XIVE_GRP_SOURCE 2 /* 64-bit source attributes */
> +#define KVM_DEV_XIVE_GRP_SOURCE_CONFIG 3 /* 64-bit source attributes */
>
> /* Layout of 64-bit XIVE source attribute values */
> #define KVM_XIVE_LEVEL_SENSITIVE (1ULL << 0)
> #define KVM_XIVE_LEVEL_ASSERTED (1ULL << 1)
>
> +/* Layout of 64-bit XIVE source configuration attribute values */
> +#define KVM_XIVE_SOURCE_PRIORITY_SHIFT 0
> +#define KVM_XIVE_SOURCE_PRIORITY_MASK 0x7
> +#define KVM_XIVE_SOURCE_SERVER_SHIFT 3
> +#define KVM_XIVE_SOURCE_SERVER_MASK 0xfffffff8ULL
> +#define KVM_XIVE_SOURCE_MASK_SHIFT 32
> +#define KVM_XIVE_SOURCE_MASK_MASK 0x100000000ULL
> +#define KVM_XIVE_SOURCE_EISN_SHIFT 33
> +#define KVM_XIVE_SOURCE_EISN_MASK 0xfffffffe00000000ULL
> +
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/arch/powerpc/kvm/book3s_xive.h b/arch/powerpc/kvm/book3s_xive.h
> index f22f2d46d0f0..ab3ac152980d 100644
> --- a/arch/powerpc/kvm/book3s_xive.h
> +++ b/arch/powerpc/kvm/book3s_xive.h
> @@ -61,6 +61,9 @@ struct kvmppc_xive_irq_state {
> bool saved_p;
> bool saved_q;
> u8 saved_scan_prio;
> +
> + /* Xive native */
> + u32 eisn; /* Guest Effective IRQ number */
> };
>
> /* Select the "right" interrupt (IPI vs. passthrough) */
> @@ -263,6 +266,7 @@ int kvmppc_xive_debug_show_queues(struct seq_file *m, struct kvm_vcpu *vcpu);
> struct kvmppc_xive_src_block *kvmppc_xive_create_src_block(
> struct kvmppc_xive *xive, int irq);
> void kvmppc_xive_free_sources(struct kvmppc_xive_src_block *sb);
> +int kvmppc_xive_select_target(struct kvm *kvm, u32 *server, u8 prio);
>
> #endif /* CONFIG_KVM_XICS */
> #endif /* _KVM_PPC_BOOK3S_XICS_H */
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index 6f950ecb3592..086da91d7c6e 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -342,7 +342,7 @@ static int xive_try_pick_queue(struct kvm_vcpu *vcpu, u8 prio)
> return atomic_add_unless(&q->count, 1, max) ? 0 : -EBUSY;
> }
>
> -static int xive_select_target(struct kvm *kvm, u32 *server, u8 prio)
> +int kvmppc_xive_select_target(struct kvm *kvm, u32 *server, u8 prio)
> {
> struct kvm_vcpu *vcpu;
> int i, rc;
> @@ -535,7 +535,7 @@ static int xive_target_interrupt(struct kvm *kvm,
> * priority. The count for that new target will have
> * already been incremented.
> */
> - rc = xive_select_target(kvm, &server, prio);
> + rc = kvmppc_xive_select_target(kvm, &server, prio);
>
> /*
> * We failed to find a target ? Not much we can do
> @@ -1509,6 +1509,7 @@ struct kvmppc_xive_src_block *kvmppc_xive_create_src_block(
>
> for (i = 0; i < KVMPPC_XICS_IRQ_PER_ICS; i++) {
> sb->irq_state[i].number = (bid << KVMPPC_XICS_ICS_SHIFT) | i;
> + sb->irq_state[i].eisn = 0;
> sb->irq_state[i].guest_priority = MASKED;
> sb->irq_state[i].saved_priority = MASKED;
> sb->irq_state[i].act_priority = MASKED;
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index a9b2d2d9af99..cb5a5c6e05af 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -248,6 +248,99 @@ static int kvmppc_xive_native_set_source(struct kvmppc_xive *xive, long irq,
> return 0;
> }
>
> +static int kvmppc_xive_native_update_source_config(struct kvmppc_xive *xive,
> + struct kvmppc_xive_src_block *sb,
> + struct kvmppc_xive_irq_state *state,
> + u32 server,
> + u8 priority,
> + u32 eisn)
> +{
> + struct kvm *kvm = xive->kvm;
> + u32 hw_num;
> + int rc = 0;
> +
> + /*
> + * TODO: Do we need to safely mask and unmask a source ? can
> + * we just let the guest handle the possible races ?
> + */
> + arch_spin_lock(&sb->lock);
> +
> + if (state->act_server == server && state->act_priority == priority &&
> + state->eisn == eisn)
> + goto unlock;
> +
> + pr_devel("new_act_prio=%d new_act_server=%d act_server=%d act_prio=%d\n",
> + priority, server, state->act_server, state->act_priority);
> +
> + kvmppc_xive_select_irq(state, &hw_num, NULL);
> +
> + if (priority != MASKED) {
> + rc = kvmppc_xive_select_target(kvm, &server, priority);
> + if (rc)
> + goto unlock;
> +
> + state->act_priority = priority;
> + state->act_server = server;
> + state->eisn = eisn;
> +
> + rc = xive_native_configure_irq(hw_num, xive->vp_base + server,
> + priority, eisn);
> + } else {
> + state->act_priority = MASKED;
> + state->act_server = 0;
> + state->eisn = 0;
> +
> + rc = xive_native_configure_irq(hw_num, 0, MASKED, 0);
> + }
> +
> +unlock:
> + arch_spin_unlock(&sb->lock);
> + return rc;
> +}
> +
> +static int kvmppc_xive_native_set_source_config(struct kvmppc_xive *xive,
> + long irq, u64 addr)
> +{
> + struct kvmppc_xive_src_block *sb;
> + struct kvmppc_xive_irq_state *state;
> + u64 __user *ubufp = (u64 __user *) addr;
> + u16 src;
> + u64 kvm_cfg;
> + u32 server;
> + u8 priority;
> + u32 eisn;
> +
> + sb = kvmppc_xive_find_source(xive, irq, &src);
> + if (!sb)
> + return -ENOENT;
> +
> + state = &sb->irq_state[src];
> +
> + if (!state->valid)
> + return -EINVAL;
> +
> + if (get_user(kvm_cfg, ubufp))
> + return -EFAULT;
> +
> + pr_devel("%s irq=0x%lx cfg=%016llx\n", __func__, irq, kvm_cfg);
> +
> + priority = (kvm_cfg & KVM_XIVE_SOURCE_PRIORITY_MASK) >>
> + KVM_XIVE_SOURCE_PRIORITY_SHIFT;
> + server = (kvm_cfg & KVM_XIVE_SOURCE_SERVER_MASK) >>
> + KVM_XIVE_SOURCE_SERVER_SHIFT;
> + eisn = (kvm_cfg & KVM_XIVE_SOURCE_EISN_MASK) >>
> + KVM_XIVE_SOURCE_EISN_SHIFT;
> +
> + if (priority != xive_prio_from_guest(priority)) {
> + pr_err("invalid priority for queue %d for VCPU %d\n",
> + priority, server);
> + return -EINVAL;
> + }
> +
> + return kvmppc_xive_native_update_source_config(xive, sb, state, server,
> + priority, eisn);
> +}
> +
> static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> @@ -259,6 +352,9 @@ static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> case KVM_DEV_XIVE_GRP_SOURCE:
> return kvmppc_xive_native_set_source(xive, attr->attr,
> attr->addr);
> + case KVM_DEV_XIVE_GRP_SOURCE_CONFIG:
> + return kvmppc_xive_native_set_source_config(xive, attr->attr,
> + attr->addr);
> }
> return -ENXIO;
> }
> @@ -276,6 +372,7 @@ static int kvmppc_xive_native_has_attr(struct kvm_device *dev,
> case KVM_DEV_XIVE_GRP_CTRL:
> break;
> case KVM_DEV_XIVE_GRP_SOURCE:
> + case KVM_DEV_XIVE_GRP_SOURCE_CONFIG:
> if (attr->attr >= KVMPPC_XIVE_FIRST_IRQ &&
> attr->attr < KVMPPC_XIVE_NR_IRQS)
> return 0;
> diff --git a/Documentation/virtual/kvm/devices/xive.txt b/Documentation/virtual/kvm/devices/xive.txt
> index cd8bfc37b72e..4f513a1880c7 100644
> --- a/Documentation/virtual/kvm/devices/xive.txt
> +++ b/Documentation/virtual/kvm/devices/xive.txt
> @@ -32,3 +32,23 @@ the legacy interrupt mode, referred as XICS (POWER7/8).
> -ENOMEM: Could not create a new source block
> -EFAULT: Invalid user pointer for attr->addr.
> -ENXIO: Could not allocate underlying HW interrupt
> +
> + 3. KVM_DEV_XIVE_GRP_SOURCE_CONFIG (write only)
> + Configures source targeting
> + Attributes:
> + Interrupt source number (64-bit)
> + The kvm_device_attr.addr points to a __u64 value:
> + bits: | 63 .... 33 | 32 | 31 .. 3 | 2 .. 0
> + values: | eisn | mask | server | priority
> + - priority: 0-7 interrupt priority level
> + - server: CPU number chosen to handle the interrupt
> + - mask: mask flag (unused)
> + - eisn: Effective Interrupt Source Number
> + Errors:
> + -ENOENT: Unknown source number
> + -EINVAL: Not initialized source number, invalid priority or
> + invalid CPU number.
> + -EFAULT: Invalid user pointer for attr->addr.
> + -ENXIO: CPU event queues not configured or configuration of the
> + underlying HW interrupt failed
> + -EBUSY: No CPU available to serve interrupt
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 02/16] KVM: PPC: Book3S HV: add a new KVM device for the XIVE native exploitation mode
From: David Gibson @ 2019-02-25 0:08 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190222112840.25000-3-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 11820 bytes --]
On Fri, Feb 22, 2019 at 12:28:26PM +0100, Cédric Le Goater wrote:
> This is the basic framework for the new KVM device supporting the XIVE
> native exploitation mode. The user interface exposes a new KVM device
> to be created by QEMU when running on a L0 hypervisor only. Support
> for nested guests is not available yet.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/include/asm/kvm_host.h | 1 +
> arch/powerpc/include/asm/kvm_ppc.h | 8 +
> arch/powerpc/include/uapi/asm/kvm.h | 3 +
> include/uapi/linux/kvm.h | 2 +
> arch/powerpc/kvm/book3s.c | 7 +-
> arch/powerpc/kvm/book3s_xive_native.c | 191 +++++++++++++++++++++
> Documentation/virtual/kvm/devices/xive.txt | 19 ++
> arch/powerpc/kvm/Makefile | 2 +-
> 8 files changed, 231 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/kvm/book3s_xive_native.c
> create mode 100644 Documentation/virtual/kvm/devices/xive.txt
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 091430339db1..9f75a75a07f2 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -220,6 +220,7 @@ extern struct kvm_device_ops kvm_xics_ops;
> struct kvmppc_xive;
> struct kvmppc_xive_vcpu;
> extern struct kvm_device_ops kvm_xive_ops;
> +extern struct kvm_device_ops kvm_xive_native_ops;
>
> struct kvmppc_passthru_irqmap;
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index b3bf4f61b30c..4b72ddde7dc1 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -593,6 +593,10 @@ extern int kvmppc_xive_set_icp(struct kvm_vcpu *vcpu, u64 icpval);
> extern int kvmppc_xive_set_irq(struct kvm *kvm, int irq_source_id, u32 irq,
> int level, bool line_status);
> extern void kvmppc_xive_push_vcpu(struct kvm_vcpu *vcpu);
> +
> +extern void kvmppc_xive_native_init_module(void);
> +extern void kvmppc_xive_native_exit_module(void);
> +
> #else
> static inline int kvmppc_xive_set_xive(struct kvm *kvm, u32 irq, u32 server,
> u32 priority) { return -1; }
> @@ -616,6 +620,10 @@ static inline int kvmppc_xive_set_icp(struct kvm_vcpu *vcpu, u64 icpval) { retur
> static inline int kvmppc_xive_set_irq(struct kvm *kvm, int irq_source_id, u32 irq,
> int level, bool line_status) { return -ENODEV; }
> static inline void kvmppc_xive_push_vcpu(struct kvm_vcpu *vcpu) { }
> +
> +static inline void kvmppc_xive_native_init_module(void) { }
> +static inline void kvmppc_xive_native_exit_module(void) { }
> +
> #endif /* CONFIG_KVM_XIVE */
>
> #ifdef CONFIG_PPC_POWERNV
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index 8c876c166ef2..b002c0c67787 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -675,4 +675,7 @@ struct kvm_ppc_cpu_char {
> #define KVM_XICS_PRESENTED (1ULL << 43)
> #define KVM_XICS_QUEUED (1ULL << 44)
>
> +/* POWER9 XIVE Native Interrupt Controller */
> +#define KVM_DEV_XIVE_GRP_CTRL 1
> +
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 6d4ea4b6c922..e6368163d3a0 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1211,6 +1211,8 @@ enum kvm_device_type {
> #define KVM_DEV_TYPE_ARM_VGIC_V3 KVM_DEV_TYPE_ARM_VGIC_V3
> KVM_DEV_TYPE_ARM_VGIC_ITS,
> #define KVM_DEV_TYPE_ARM_VGIC_ITS KVM_DEV_TYPE_ARM_VGIC_ITS
> + KVM_DEV_TYPE_XIVE,
> +#define KVM_DEV_TYPE_XIVE KVM_DEV_TYPE_XIVE
> KVM_DEV_TYPE_MAX,
> };
>
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index 601c094f15ab..96d43f091255 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -1040,6 +1040,9 @@ static int kvmppc_book3s_init(void)
> if (xics_on_xive()) {
> kvmppc_xive_init_module();
> kvm_register_device_ops(&kvm_xive_ops, KVM_DEV_TYPE_XICS);
> + kvmppc_xive_native_init_module();
> + kvm_register_device_ops(&kvm_xive_native_ops,
> + KVM_DEV_TYPE_XIVE);
> } else
> #endif
> kvm_register_device_ops(&kvm_xics_ops, KVM_DEV_TYPE_XICS);
> @@ -1050,8 +1053,10 @@ static int kvmppc_book3s_init(void)
> static void kvmppc_book3s_exit(void)
> {
> #ifdef CONFIG_KVM_XICS
> - if (xics_on_xive())
> + if (xics_on_xive()) {
> kvmppc_xive_exit_module();
> + kvmppc_xive_native_exit_module();
> + }
> #endif
> #ifdef CONFIG_KVM_BOOK3S_32_HANDLER
> kvmppc_book3s_exit_pr();
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> new file mode 100644
> index 000000000000..e475ce83ad14
> --- /dev/null
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2017-2019, IBM Corporation.
> + */
> +
> +#define pr_fmt(fmt) "xive-kvm: " fmt
> +
> +#include <linux/anon_inodes.h>
> +#include <linux/kernel.h>
> +#include <linux/kvm_host.h>
> +#include <linux/err.h>
> +#include <linux/gfp.h>
> +#include <linux/spinlock.h>
> +#include <linux/delay.h>
> +#include <linux/percpu.h>
> +#include <linux/cpumask.h>
> +#include <asm/uaccess.h>
> +#include <asm/kvm_book3s.h>
> +#include <asm/kvm_ppc.h>
> +#include <asm/hvcall.h>
> +#include <asm/xics.h>
> +#include <asm/xive.h>
> +#include <asm/xive-regs.h>
> +#include <asm/debug.h>
> +#include <asm/debugfs.h>
> +#include <asm/time.h>
> +#include <asm/opal.h>
> +
> +#include <linux/debugfs.h>
> +#include <linux/seq_file.h>
> +
> +#include "book3s_xive.h"
> +
> +static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_XIVE_GRP_CTRL:
> + break;
> + }
> + return -ENXIO;
> +}
> +
> +static int kvmppc_xive_native_get_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + return -ENXIO;
> +}
> +
> +static int kvmppc_xive_native_has_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr)
> +{
> + switch (attr->group) {
> + case KVM_DEV_XIVE_GRP_CTRL:
> + break;
> + }
> + return -ENXIO;
> +}
> +
> +static void kvmppc_xive_native_free(struct kvm_device *dev)
> +{
> + struct kvmppc_xive *xive = dev->private;
> + struct kvm *kvm = xive->kvm;
> +
> + debugfs_remove(xive->dentry);
> +
> + pr_devel("Destroying xive native device\n");
> +
> + if (kvm)
> + kvm->arch.xive = NULL;
> +
> + if (xive->vp_base != XIVE_INVALID_VP)
> + xive_native_free_vp_block(xive->vp_base);
> +
> + kfree(xive);
> + kfree(dev);
> +}
> +
> +static int kvmppc_xive_native_create(struct kvm_device *dev, u32 type)
> +{
> + struct kvmppc_xive *xive;
> + struct kvm *kvm = dev->kvm;
> + int ret = 0;
> +
> + pr_devel("Creating xive native device\n");
> +
> + if (kvm->arch.xive)
> + return -EEXIST;
> +
> + xive = kzalloc(sizeof(*xive), GFP_KERNEL);
> + if (!xive)
> + return -ENOMEM;
> +
> + dev->private = xive;
> + xive->dev = dev;
> + xive->kvm = kvm;
> + kvm->arch.xive = xive;
> +
> + /* We use the default queue size set by the host */
IIUC the queue is examined directly by the guest, so the guest must
know its size. In which case letting the host decide the size would
be a problem for migration.
> + xive->q_order = xive_native_default_eq_shift();
> + if (xive->q_order < PAGE_SHIFT)
> + xive->q_page_order = 0;
> + else
> + xive->q_page_order = xive->q_order - PAGE_SHIFT;
> +
> + /*
> + * Allocate a bunch of VPs. KVM_MAX_VCPUS is a large value for
> + * a default. Getting the max number of CPUs the VM was
> + * configured with would improve our usage of the XIVE VP space.
> + */
> + xive->vp_base = xive_native_alloc_vp_block(KVM_MAX_VCPUS);
> + pr_devel("VP_Base=%x\n", xive->vp_base);
> +
> + if (xive->vp_base == XIVE_INVALID_VP)
> + ret = -ENOMEM;
> +
> + xive->single_escalation = xive_native_has_single_escalation();
> +
> + if (ret)
> + kfree(xive);
> +
> + return ret;
> +}
> +
> +static int xive_native_debug_show(struct seq_file *m, void *private)
> +{
> + struct kvmppc_xive *xive = m->private;
> + struct kvm *kvm = xive->kvm;
> +
> + if (!kvm)
> + return 0;
> +
> + return 0;
> +}
> +
> +static int xive_native_debug_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, xive_native_debug_show, inode->i_private);
> +}
> +
> +static const struct file_operations xive_native_debug_fops = {
> + .open = xive_native_debug_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
> +
> +static void xive_native_debugfs_init(struct kvmppc_xive *xive)
> +{
> + char *name;
> +
> + name = kasprintf(GFP_KERNEL, "kvm-xive-%p", xive);
> + if (!name) {
> + pr_err("%s: no memory for name\n", __func__);
> + return;
> + }
> +
> + xive->dentry = debugfs_create_file(name, 0444, powerpc_debugfs_root,
> + xive, &xive_native_debug_fops);
> +
> + pr_debug("%s: created %s\n", __func__, name);
> + kfree(name);
> +}
> +
> +static void kvmppc_xive_native_init(struct kvm_device *dev)
> +{
> + struct kvmppc_xive *xive = (struct kvmppc_xive *)dev->private;
> +
> + /* Register some debug interfaces */
> + xive_native_debugfs_init(xive);
> +}
> +
> +struct kvm_device_ops kvm_xive_native_ops = {
> + .name = "kvm-xive-native",
> + .create = kvmppc_xive_native_create,
> + .init = kvmppc_xive_native_init,
> + .destroy = kvmppc_xive_native_free,
> + .set_attr = kvmppc_xive_native_set_attr,
> + .get_attr = kvmppc_xive_native_get_attr,
> + .has_attr = kvmppc_xive_native_has_attr,
> +};
> +
> +void kvmppc_xive_native_init_module(void)
> +{
> + ;
> +}
> +
> +void kvmppc_xive_native_exit_module(void)
> +{
> + ;
> +}
> diff --git a/Documentation/virtual/kvm/devices/xive.txt b/Documentation/virtual/kvm/devices/xive.txt
> new file mode 100644
> index 000000000000..fdbd2ff92a88
> --- /dev/null
> +++ b/Documentation/virtual/kvm/devices/xive.txt
> @@ -0,0 +1,19 @@
> +POWER9 eXternal Interrupt Virtualization Engine (XIVE Gen1)
> +==========================================================
> +
> +Device types supported:
> + KVM_DEV_TYPE_XIVE POWER9 XIVE Interrupt Controller generation 1
> +
> +This device acts as a VM interrupt controller. It provides the KVM
> +interface to configure the interrupt sources of a VM in the underlying
> +POWER9 XIVE interrupt controller.
> +
> +Only one XIVE instance may be instantiated. A guest XIVE device
> +requires a POWER9 host and the guest OS should have support for the
> +XIVE native exploitation interrupt mode. If not, it should run using
> +the legacy interrupt mode, referred as XICS (POWER7/8).
> +
> +* Groups:
> +
> + 1. KVM_DEV_XIVE_GRP_CTRL
> + Provides global controls on the device
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index 64f1135e7732..806cbe488410 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -99,7 +99,7 @@ endif
> kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
> book3s_xics.o
>
> -kvm-book3s_64-objs-$(CONFIG_KVM_XIVE) += book3s_xive.o
> +kvm-book3s_64-objs-$(CONFIG_KVM_XIVE) += book3s_xive.o book3s_xive_native.o
> kvm-book3s_64-objs-$(CONFIG_SPAPR_TCE_IOMMU) += book3s_64_vio.o
>
> kvm-book3s_64-module-objs := \
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 03/16] KVM: PPC: Book3S HV: XIVE: introduce a new capability KVM_CAP_PPC_IRQ_XIVE
From: David Gibson @ 2019-02-25 0:35 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190222112840.25000-4-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 15259 bytes --]
On Fri, Feb 22, 2019 at 12:28:27PM +0100, Cédric Le Goater wrote:
> The user interface exposes a new capability to let QEMU connect the
> vCPU to the XIVE KVM device if required. The capability is only
> advertised on a PowerNV Hypervisor as support for nested guests
> (pseries KVM Hypervisor) is not yet available.
>
> Internally, the interface to the new KVM device is protected with a
> new interrupt mode: KVMPPC_IRQ_XIVE.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/include/asm/kvm_host.h | 1 +
> arch/powerpc/include/asm/kvm_ppc.h | 13 +++
> arch/powerpc/kvm/book3s_xive.h | 6 ++
> include/uapi/linux/kvm.h | 1 +
> arch/powerpc/kvm/book3s_xive.c | 67 +++++++-----
> arch/powerpc/kvm/book3s_xive_native.c | 144 ++++++++++++++++++++++++++
> arch/powerpc/kvm/powerpc.c | 33 ++++++
> Documentation/virtual/kvm/api.txt | 9 ++
> 8 files changed, 246 insertions(+), 28 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
> index 9f75a75a07f2..eb8581be0ee8 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -448,6 +448,7 @@ struct kvmppc_passthru_irqmap {
> #define KVMPPC_IRQ_DEFAULT 0
> #define KVMPPC_IRQ_MPIC 1
> #define KVMPPC_IRQ_XICS 2 /* Includes a XIVE option */
> +#define KVMPPC_IRQ_XIVE 3 /* XIVE native exploitation mode */
>
> #define MMIO_HPTE_CACHE_SIZE 4
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index 4b72ddde7dc1..1e61877fe147 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -594,6 +594,14 @@ extern int kvmppc_xive_set_irq(struct kvm *kvm, int irq_source_id, u32 irq,
> int level, bool line_status);
> extern void kvmppc_xive_push_vcpu(struct kvm_vcpu *vcpu);
>
> +static inline int kvmppc_xive_enabled(struct kvm_vcpu *vcpu)
> +{
> + return vcpu->arch.irq_type == KVMPPC_IRQ_XIVE;
> +}
> +
> +extern int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev,
> + struct kvm_vcpu *vcpu, u32 cpu);
> +extern void kvmppc_xive_native_cleanup_vcpu(struct kvm_vcpu *vcpu);
> extern void kvmppc_xive_native_init_module(void);
> extern void kvmppc_xive_native_exit_module(void);
>
> @@ -621,6 +629,11 @@ static inline int kvmppc_xive_set_irq(struct kvm *kvm, int irq_source_id, u32 ir
> int level, bool line_status) { return -ENODEV; }
> static inline void kvmppc_xive_push_vcpu(struct kvm_vcpu *vcpu) { }
>
> +static inline int kvmppc_xive_enabled(struct kvm_vcpu *vcpu)
> + { return 0; }
> +static inline int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev,
> + struct kvm_vcpu *vcpu, u32 cpu) { return -EBUSY; }
> +static inline void kvmppc_xive_native_cleanup_vcpu(struct kvm_vcpu *vcpu) { }
> static inline void kvmppc_xive_native_init_module(void) { }
> static inline void kvmppc_xive_native_exit_module(void) { }
>
> diff --git a/arch/powerpc/kvm/book3s_xive.h b/arch/powerpc/kvm/book3s_xive.h
> index a08ae6fd4c51..bcb1bbcf0359 100644
> --- a/arch/powerpc/kvm/book3s_xive.h
> +++ b/arch/powerpc/kvm/book3s_xive.h
> @@ -248,5 +248,11 @@ extern int (*__xive_vm_h_ipi)(struct kvm_vcpu *vcpu, unsigned long server,
> extern int (*__xive_vm_h_cppr)(struct kvm_vcpu *vcpu, unsigned long cppr);
> extern int (*__xive_vm_h_eoi)(struct kvm_vcpu *vcpu, unsigned long xirr);
>
> +/*
> + * Common Xive routines for XICS-over-XIVE and XIVE native
> + */
> +void kvmppc_xive_disable_vcpu_interrupts(struct kvm_vcpu *vcpu);
> +int kvmppc_xive_debug_show_queues(struct seq_file *m, struct kvm_vcpu *vcpu);
> +
> #endif /* CONFIG_KVM_XICS */
> #endif /* _KVM_PPC_BOOK3S_XICS_H */
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index e6368163d3a0..52bf74a1616e 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -988,6 +988,7 @@ struct kvm_ppc_resize_hpt {
> #define KVM_CAP_ARM_VM_IPA_SIZE 165
> #define KVM_CAP_MANUAL_DIRTY_LOG_PROTECT 166
> #define KVM_CAP_HYPERV_CPUID 167
> +#define KVM_CAP_PPC_IRQ_XIVE 168
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> index f78d002f0fe0..d1cc18a5b1c4 100644
> --- a/arch/powerpc/kvm/book3s_xive.c
> +++ b/arch/powerpc/kvm/book3s_xive.c
> @@ -1049,7 +1049,7 @@ int kvmppc_xive_clr_mapped(struct kvm *kvm, unsigned long guest_irq,
> }
> EXPORT_SYMBOL_GPL(kvmppc_xive_clr_mapped);
>
> -static void kvmppc_xive_disable_vcpu_interrupts(struct kvm_vcpu *vcpu)
> +void kvmppc_xive_disable_vcpu_interrupts(struct kvm_vcpu *vcpu)
> {
> struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> struct kvm *kvm = vcpu->kvm;
> @@ -1883,6 +1883,43 @@ static int kvmppc_xive_create(struct kvm_device *dev, u32 type)
> return 0;
> }
>
> +int kvmppc_xive_debug_show_queues(struct seq_file *m, struct kvm_vcpu *vcpu)
> +{
> + struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> + unsigned int i;
> +
> + for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) {
> + struct xive_q *q = &xc->queues[i];
> + u32 i0, i1, idx;
> +
> + if (!q->qpage && !xc->esc_virq[i])
> + continue;
> +
> + seq_printf(m, " [q%d]: ", i);
> +
> + if (q->qpage) {
> + idx = q->idx;
> + i0 = be32_to_cpup(q->qpage + idx);
> + idx = (idx + 1) & q->msk;
> + i1 = be32_to_cpup(q->qpage + idx);
> + seq_printf(m, "T=%d %08x %08x...\n", q->toggle,
> + i0, i1);
> + }
> + if (xc->esc_virq[i]) {
> + struct irq_data *d = irq_get_irq_data(xc->esc_virq[i]);
> + struct xive_irq_data *xd =
> + irq_data_get_irq_handler_data(d);
> + u64 pq = xive_vm_esb_load(xd, XIVE_ESB_GET);
> +
> + seq_printf(m, "E:%c%c I(%d:%llx:%llx)",
> + (pq & XIVE_ESB_VAL_P) ? 'P' : 'p',
> + (pq & XIVE_ESB_VAL_Q) ? 'Q' : 'q',
> + xc->esc_virq[i], pq, xd->eoi_page);
> + seq_puts(m, "\n");
> + }
> + }
> + return 0;
> +}
>
> static int xive_debug_show(struct seq_file *m, void *private)
> {
> @@ -1908,7 +1945,6 @@ static int xive_debug_show(struct seq_file *m, void *private)
>
> kvm_for_each_vcpu(i, vcpu, kvm) {
> struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> - unsigned int i;
>
> if (!xc)
> continue;
> @@ -1918,33 +1954,8 @@ static int xive_debug_show(struct seq_file *m, void *private)
> xc->server_num, xc->cppr, xc->hw_cppr,
> xc->mfrr, xc->pending,
> xc->stat_rm_h_xirr, xc->stat_vm_h_xirr);
> - for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) {
> - struct xive_q *q = &xc->queues[i];
> - u32 i0, i1, idx;
>
> - if (!q->qpage && !xc->esc_virq[i])
> - continue;
> -
> - seq_printf(m, " [q%d]: ", i);
> -
> - if (q->qpage) {
> - idx = q->idx;
> - i0 = be32_to_cpup(q->qpage + idx);
> - idx = (idx + 1) & q->msk;
> - i1 = be32_to_cpup(q->qpage + idx);
> - seq_printf(m, "T=%d %08x %08x... \n", q->toggle, i0, i1);
> - }
> - if (xc->esc_virq[i]) {
> - struct irq_data *d = irq_get_irq_data(xc->esc_virq[i]);
> - struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
> - u64 pq = xive_vm_esb_load(xd, XIVE_ESB_GET);
> - seq_printf(m, "E:%c%c I(%d:%llx:%llx)",
> - (pq & XIVE_ESB_VAL_P) ? 'P' : 'p',
> - (pq & XIVE_ESB_VAL_Q) ? 'Q' : 'q',
> - xc->esc_virq[i], pq, xd->eoi_page);
> - seq_printf(m, "\n");
> - }
> - }
> + kvmppc_xive_debug_show_queues(m, vcpu);
>
> t_rm_h_xirr += xc->stat_rm_h_xirr;
> t_rm_h_ipoll += xc->stat_rm_h_ipoll;
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index e475ce83ad14..1f3da47a4a6a 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -31,6 +31,128 @@
>
> #include "book3s_xive.h"
>
> +static void kvmppc_xive_native_cleanup_queue(struct kvm_vcpu *vcpu, int prio)
> +{
> + struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> + struct xive_q *q = &xc->queues[prio];
> +
> + xive_native_disable_queue(xc->vp_id, q, prio);
> + if (q->qpage) {
> + put_page(virt_to_page(q->qpage));
> + q->qpage = NULL;
> + }
> +}
> +
> +void kvmppc_xive_native_cleanup_vcpu(struct kvm_vcpu *vcpu)
> +{
> + struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> + int i;
> +
> + if (!kvmppc_xive_enabled(vcpu))
> + return;
> +
> + if (!xc)
> + return;
> +
> + pr_devel("native_cleanup_vcpu(cpu=%d)\n", xc->server_num);
> +
> + /* Ensure no interrupt is still routed to that VP */
> + xc->valid = false;
> + kvmppc_xive_disable_vcpu_interrupts(vcpu);
> +
> + /* Disable the VP */
> + xive_native_disable_vp(xc->vp_id);
> +
> + /* Free the queues & associated interrupts */
> + for (i = 0; i < KVMPPC_XIVE_Q_COUNT; i++) {
> + /* Free the escalation irq */
> + if (xc->esc_virq[i]) {
> + free_irq(xc->esc_virq[i], vcpu);
> + irq_dispose_mapping(xc->esc_virq[i]);
> + kfree(xc->esc_virq_names[i]);
> + xc->esc_virq[i] = 0;
> + }
> +
> + /* Free the queue */
> + kvmppc_xive_native_cleanup_queue(vcpu, i);
> + }
> +
> + /* Free the VP */
> + kfree(xc);
> +
> + /* Cleanup the vcpu */
> + vcpu->arch.irq_type = KVMPPC_IRQ_DEFAULT;
> + vcpu->arch.xive_vcpu = NULL;
> +}
> +
> +int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev,
> + struct kvm_vcpu *vcpu, u32 cpu)
> +{
> + struct kvmppc_xive *xive = dev->private;
> + struct kvmppc_xive_vcpu *xc;
> + int rc;
> +
> + pr_devel("native_connect_vcpu(cpu=%d)\n", cpu);
> +
> + if (dev->ops != &kvm_xive_native_ops) {
> + pr_devel("Wrong ops !\n");
> + return -EPERM;
> + }
> + if (xive->kvm != vcpu->kvm)
> + return -EPERM;
> + if (vcpu->arch.irq_type != KVMPPC_IRQ_DEFAULT)
> + return -EBUSY;
> + if (kvmppc_xive_find_server(vcpu->kvm, cpu)) {
You haven't taken the kvm->lock yet, so couldn't a race mean a
duplicate server gets inserted after you make this check?
> + pr_devel("Duplicate !\n");
> + return -EEXIST;
> + }
> + if (cpu >= KVM_MAX_VCPUS) {
> + pr_devel("Out of bounds !\n");
> + return -EINVAL;
> + }
> + xc = kzalloc(sizeof(*xc), GFP_KERNEL);
> + if (!xc)
> + return -ENOMEM;
> +
> + mutex_lock(&vcpu->kvm->lock);
> + vcpu->arch.xive_vcpu = xc;
Similarly you don't verify this is NULL after taking the lock, so
couldn't another thread race and make a connect which gets clobbered
here?
> + xc->xive = xive;
> + xc->vcpu = vcpu;
> + xc->server_num = cpu;
> + xc->vp_id = xive->vp_base + cpu;
Hrm. This ties the internal VP id to the userspace chosen server
number, which isn't ideal. It puts a constraint on those server
numbers that you wouldn't otherwise have.
> + xc->valid = true;
> +
> + rc = xive_native_get_vp_info(xc->vp_id, &xc->vp_cam, &xc->vp_chip_id);
> + if (rc) {
> + pr_err("Failed to get VP info from OPAL: %d\n", rc);
> + goto bail;
> + }
> +
> + /*
> + * Enable the VP first as the single escalation mode will
> + * affect escalation interrupts numbering
> + */
> + rc = xive_native_enable_vp(xc->vp_id, xive->single_escalation);
> + if (rc) {
> + pr_err("Failed to enable VP in OPAL: %d\n", rc);
> + goto bail;
> + }
> +
> + /* Configure VCPU fields for use by assembly push/pull */
> + vcpu->arch.xive_saved_state.w01 = cpu_to_be64(0xff000000);
> + vcpu->arch.xive_cam_word = cpu_to_be32(xc->vp_cam | TM_QW1W2_VO);
> +
> + /* TODO: initialize queues ? */
> +
> +bail:
> + vcpu->arch.irq_type = KVMPPC_IRQ_XIVE;
> + mutex_unlock(&vcpu->kvm->lock);
> + if (rc)
> + kvmppc_xive_native_cleanup_vcpu(vcpu);
> +
> + return rc;
> +}
> +
> static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> @@ -126,10 +248,32 @@ static int xive_native_debug_show(struct seq_file *m, void *private)
> {
> struct kvmppc_xive *xive = m->private;
> struct kvm *kvm = xive->kvm;
> + struct kvm_vcpu *vcpu;
> + unsigned int i;
>
> if (!kvm)
> return 0;
>
> + seq_puts(m, "=========\nVCPU state\n=========\n");
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> +
> + if (!xc)
> + continue;
> +
> + seq_printf(m, "cpu server %#x NSR=%02x CPPR=%02x IBP=%02x PIPR=%02x w01=%016llx w2=%08x\n",
> + xc->server_num,
> + vcpu->arch.xive_saved_state.nsr,
> + vcpu->arch.xive_saved_state.cppr,
> + vcpu->arch.xive_saved_state.ipb,
> + vcpu->arch.xive_saved_state.pipr,
> + vcpu->arch.xive_saved_state.w01,
> + (u32) vcpu->arch.xive_cam_word);
> +
> + kvmppc_xive_debug_show_queues(m, vcpu);
> + }
> +
> return 0;
> }
>
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 8c69af10f91d..a38a643a24dd 100644
> --- a/arch/powerpc/kvm/powerpc.c
> +++ b/arch/powerpc/kvm/powerpc.c
> @@ -570,6 +570,12 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> case KVM_CAP_PPC_GET_CPU_CHAR:
> r = 1;
> break;
> +#ifdef CONFIG_KVM_XIVE
> + case KVM_CAP_PPC_IRQ_XIVE:
> + /* only for PowerNV */
> + r = !!cpu_has_feature(CPU_FTR_HVMODE);
> + break;
> +#endif
>
> case KVM_CAP_PPC_ALLOC_HTAB:
> r = hv_enabled;
> @@ -753,6 +759,9 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
> else
> kvmppc_xics_free_icp(vcpu);
> break;
> + case KVMPPC_IRQ_XIVE:
> + kvmppc_xive_native_cleanup_vcpu(vcpu);
> + break;
> }
>
> kvmppc_core_vcpu_free(vcpu);
> @@ -1941,6 +1950,30 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
> break;
> }
> #endif /* CONFIG_KVM_XICS */
> +#ifdef CONFIG_KVM_XIVE
> + case KVM_CAP_PPC_IRQ_XIVE: {
> + struct fd f;
> + struct kvm_device *dev;
> +
> + r = -EBADF;
> + f = fdget(cap->args[0]);
> + if (!f.file)
> + break;
> +
> + r = -ENXIO;
> + if (!xive_enabled())
> + break;
> +
> + r = -EPERM;
> + dev = kvm_device_from_filp(f.file);
> + if (dev)
> + r = kvmppc_xive_native_connect_vcpu(dev, vcpu,
> + cap->args[1]);
> +
> + fdput(f);
> + break;
> + }
> +#endif /* CONFIG_KVM_XIVE */
> #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> case KVM_CAP_PPC_FWNMI:
> r = -EINVAL;
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 356156f5c52d..1db1435769b4 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -4458,6 +4458,15 @@ struct kvm_sync_regs {
> struct kvm_vcpu_events events;
> };
>
> +6.75 KVM_CAP_PPC_IRQ_XIVE
> +
> +Architectures: ppc
> +Target: vcpu
> +Parameters: args[0] is the XIVE device fd
> + args[1] is the XIVE CPU number (server ID) for this vcpu
> +
> +This capability connects the vcpu to an in-kernel XIVE device.
> +
> 7. Capabilities that can be enabled on VMs
> ------------------------------------------
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/16] powerpc/xive: add OPAL extensions for the XIVE native exploitation support
From: Michael Ellerman @ 2019-02-25 3:50 UTC (permalink / raw)
To: Cédric Le Goater, kvm-ppc, Stewart Smith
Cc: kvm, Paul Mackerras, Cédric Le Goater, linuxppc-dev,
David Gibson
In-Reply-To: <20190222112840.25000-2-clg@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> 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 <clg@kaod.org>
> ---
> arch/powerpc/include/asm/opal-api.h | 11 ++-
> arch/powerpc/include/asm/opal.h | 7 ++
> arch/powerpc/include/asm/xive.h | 14 +++
> arch/powerpc/sysdev/xive/native.c | 99 +++++++++++++++++++
> .../powerpc/platforms/powernv/opal-wrappers.S | 3 +
> 5 files changed, 130 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
> index 870fb7b239ea..cdfc54f78101 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -186,8 +186,8 @@
> #define OPAL_XIVE_FREE_IRQ 140
> #define OPAL_XIVE_SYNC 141
> #define OPAL_XIVE_DUMP 142
> -#define OPAL_XIVE_RESERVED3 143
> -#define OPAL_XIVE_RESERVED4 144
> +#define OPAL_XIVE_GET_QUEUE_STATE 143
> +#define OPAL_XIVE_SET_QUEUE_STATE 144
> #define OPAL_SIGNAL_SYSTEM_RESET 145
> #define OPAL_NPU_INIT_CONTEXT 146
> #define OPAL_NPU_DESTROY_CONTEXT 147
> @@ -209,8 +209,11 @@
> #define OPAL_SENSOR_GROUP_ENABLE 163
> #define OPAL_PCI_GET_PBCQ_TUNNEL_BAR 164
> #define OPAL_PCI_SET_PBCQ_TUNNEL_BAR 165
> -#define OPAL_NX_COPROC_INIT 167
> -#define OPAL_LAST 167
> +#define OPAL_HANDLE_HMI2 166
> +#define OPAL_NX_COPROC_INIT 167
> +#define OPAL_NPU_SET_RELAXED_ORDER 168
> +#define OPAL_NPU_GET_RELAXED_ORDER 169
> +#define OPAL_XIVE_GET_VP_STATE 170
You should only be defining the calls you need, leaving gaps for other
things, and you need to retain OPAL_LAST. So it should look more like:
-#define OPAL_LAST 167
+#define OPAL_XIVE_GET_VP_STATE 170
+#define OPAL_LAST 170
Also I can't merge this until it's merged into skiboot.
cheers
^ permalink raw reply
* [PATCH V2] ASoC: fsl_esai: fix channel swap issue when stream starts
From: S.j. Wang @ 2019-02-25 2:48 UTC (permalink / raw)
To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
festevam@gmail.com, broonie@kernel.org,
alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
There is very low possibility ( < 0.1% ) that channel swap happened
in beginning when multi output/input pin is enabled. The issue is
that hardware can't send data to correct pin in the beginning with
the normal enable flow.
This is hardware issue, but there is no errata, the workaround flow
is that: Each time playback/recording, firstly clear the xSMA/xSMB,
then enable TE/RE, then enable xSMB and xSMA (xSMB must be enabled
before xSMA). Which is to use the xSMA as the trigger start register,
previously the xCR_TE or xCR_RE is the bit for starting.
Fixes 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver")
Cc: <stable@vger.kernel.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
Changes in v2
- update commit comments.
sound/soc/fsl/fsl_esai.c | 32 ++++++++++++++++++++++----------
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index afe67c865330..23bd0ad4ac31 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -54,6 +54,8 @@ struct fsl_esai {
u32 fifo_depth;
u32 slot_width;
u32 slots;
+ u32 tx_mask;
+ u32 rx_mask;
u32 hck_rate[2];
u32 sck_rate[2];
bool hck_dir[2];
@@ -361,21 +363,13 @@ static int fsl_esai_set_dai_tdm_slot(struct snd_soc_dai *dai, u32 tx_mask,
regmap_update_bits(esai_priv->regmap, REG_ESAI_TCCR,
ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMA,
- ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(tx_mask));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_TSMB,
- ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(tx_mask));
-
regmap_update_bits(esai_priv->regmap, REG_ESAI_RCCR,
ESAI_xCCR_xDC_MASK, ESAI_xCCR_xDC(slots));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMA,
- ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(rx_mask));
- regmap_update_bits(esai_priv->regmap, REG_ESAI_RSMB,
- ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(rx_mask));
-
esai_priv->slot_width = slot_width;
esai_priv->slots = slots;
+ esai_priv->tx_mask = tx_mask;
+ esai_priv->rx_mask = rx_mask;
return 0;
}
@@ -596,6 +590,7 @@ static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
u8 i, channels = substream->runtime->channels;
u32 pins = DIV_ROUND_UP(channels, esai_priv->slots);
+ u32 mask;
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -611,12 +606,23 @@ static int fsl_esai_trigger(struct snd_pcm_substream *substream, int cmd,
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK,
tx ? ESAI_xCR_TE(pins) : ESAI_xCR_RE(pins));
+ mask = tx ? esai_priv->tx_mask : esai_priv->rx_mask;
+
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
+ ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(mask));
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
+ ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(mask));
+
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
+ ESAI_xSMA_xS_MASK, 0);
+ regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMB(tx),
+ ESAI_xSMB_xS_MASK, 0);
/* Disable and reset FIFO */
regmap_update_bits(esai_priv->regmap, REG_ESAI_xFCR(tx),
@@ -906,6 +912,12 @@ static int fsl_esai_probe(struct platform_device *pdev)
return ret;
}
+ /* Clear the TSMA, TSMB, RSMA, RSMB */
+ regmap_write(esai_priv->regmap, REG_ESAI_TSMA, 0);
+ regmap_write(esai_priv->regmap, REG_ESAI_TSMB, 0);
+ regmap_write(esai_priv->regmap, REG_ESAI_RSMA, 0);
+ regmap_write(esai_priv->regmap, REG_ESAI_RSMB, 0);
+
ret = devm_snd_soc_register_component(&pdev->dev, &fsl_esai_component,
&fsl_esai_dai, 1);
if (ret) {
--
1.9.1
^ permalink raw reply related
* RE: [PATCH] ASoC: fsl_esai: fix channel swap issue when stream starts
From: S.j. Wang @ 2019-02-25 2:31 UTC (permalink / raw)
To: Fabio Estevam
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, nicoleotsuka@gmail.com, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOMZO5A-XCxtNmO5+JM+9R34oh-dYUD8ZHynCUE_p_Q-kjvR0w@mail.gmail.com>
Thanks, will send v2.
Best regards
Wang shengjiu
>
> Hi Shengjiu.
>
> On Thu, Feb 21, 2019 at 6:53 AM S.j. Wang <shengjiu.wang@nxp.com>
> wrote:
> >
> > From: Shengjiu Wang <shengjiu.wang@freescale.com>
>
> Better use your nxp.com address as the freescale.com domain is gone for a
> long time.
>
> > There is very low possibility ( < 0.1% ) that channel swap happened in
> > beginning when multi output/input pin is enabled. The issue is that
> > hardware can't send data to correct pin in the begginning with
>
> s/begginning/beginning
>
> > the normal enable flow.
> >
> > This is hardware issue, the workaround flow is that: Each time
>
> Is there an erratum reference for this issue? If so, please add it here.
>
> > playback/recording, firstly clear the xSMA/xSMB, then enable TE/RE,
> > then enable xSMB and xSMA (xSMB must be enabled before xSMA).
> > Which is to use the xSMA as the trigger start register, previously the
> > xCR_TE or xCR_RE is the bit for starting
>
> Please add a Fixes tag and Cc stable.
>
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@freescale.com>
>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
>
> Thanks
^ permalink raw reply
* Re: linux-next: Signed-off-by missing for commit in the powerpc tree
From: Stephen Rothwell @ 2019-02-24 22:47 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linux Next Mailing List, PowerPC, Linux Kernel Mailing List
In-Reply-To: <8736odl846.fsf@concordia.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
Hi Michael,
On Sun, 24 Feb 2019 22:48:57 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> But do they need SOBs?
I think so, since they modify the code ..
> The DCO says:
>
> By making a contribution to this project, I certify that:
>
> (a) The contribution was created in whole or in part by me and I
> have the right to submit it under the open source license
> indicated in the file; or
>
> (b) The contribution is based upon previous work that, to the best
> of my knowledge, is covered under an appropriate open source
> license and I have the right under that license to submit that
> work with modifications, whether created in whole or in part
> by me, under the same open source license (unless I am
> permitted to submit under a different license), as indicated
> in the file; or
>
> (c) The contribution was provided directly to me by some other
> person who certified (a), (b) or (c) and I have not modified
> it.
>
> (d) I understand and agree that this project and the contribution
> are public and that a record of the contribution (including all
> personal information I submit with it, including my sign-off) is
> maintained indefinitely and may be redistributed consistent with
> this project or the open source license(s) involved.
>
>
> Only d) really applies to a revert, and as the maintainer I feel like d)
> is kind of implied.
I read this as (a || b || c) && d. And if there is no SOB, then none
of the above is certified.
> Anyway I'll try and remember to do it in future if that's The Rule ;)
Its just as effective as the rest of our rules ... i.e. a strong
suggestion :-)
Thanks
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: Signed-off-by missing for commit in the powerpc tree
From: Michael Ellerman @ 2019-02-24 11:48 UTC (permalink / raw)
To: Stephen Rothwell, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20190224010511.74f25272@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> Commit
>
> f68e7927212f ("Revert "powerpc/book3s32: Reorder _PAGE_XXX flags to simplify TLB handling"")
>
> is missing a Signed-off-by from its author and committer.
>
> Reverts are commits as well :-)
But do they need SOBs?
The DCO says:
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Only d) really applies to a revert, and as the maintainer I feel like d)
is kind of implied.
Anyway I'll try and remember to do it in future if that's The Rule ;)
cheers
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.0-6 tag
From: pr-tracker-bot @ 2019-02-23 19:35 UTC (permalink / raw)
To: Michael Ellerman; +Cc: aik, linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <87ftsellk0.fsf@concordia.ellerman.id.au>
The pull request you sent on Sat, 23 Feb 2019 23:46:23 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.0-6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e60b5f79bd7529e76b13cf1e85823abbd0e33634
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH V3 00/10] X86/KVM/Hyper-V: Add HV ept tlb range list flush support in KVM
From: Tianyu Lan @ 2019-02-23 14:37 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, Radim Krcmar, will.deacon, christoffer.dall, H. Peter Anvin,
kys, kvmarm, Sasha Levin, sthemmin, the arch/x86 maintainers,
linux, michael.h.kelley, Ingo Molnar, catalin.marinas, jhogan,
linux-mips, Lan Tianyu, marc.zyngier, haiyangz, kvm-ppc, bp,
Thomas Gleixner, linux-arm-kernel, linux-kernel@vger kernel org,
ralf, paul.burton, devel, Vitaly Kuznetsov, linuxppc-dev
In-Reply-To: <75e9238a-f168-b90d-e1f1-89938e6df57a@redhat.com>
On Sat, Feb 23, 2019 at 2:26 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 22/02/19 16:06, lantianyu1986@gmail.com wrote:
> > From: Lan Tianyu <Tianyu.Lan@microsoft.com>
> >
> > This patchset is to introduce hv ept tlb range list flush function
> > support in the KVM MMU component. Flushing ept tlbs of several address
> > range can be done via single hypercall and new list flush function is
> > used in the kvm_mmu_commit_zap_page() and FNAME(sync_page). This patchset
> > also adds more hv ept tlb range flush support in more KVM MMU function.
> >
> > This patchset is based on the fix patch "x86/Hyper-V: Fix definition HV_MAX_FLUSH_REP_COUNT".
> > (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1939455.html)
>
> Note that this won't make it in 5.1 unless Linus releases an -rc8.
> Otherwise, I'll get to it next week.
Hi Paolo:
Sure. Thanks for your review.
--
Best regards
Tianyu Lan
^ permalink raw reply
* linux-next: Signed-off-by missing for commit in the powerpc tree
From: Stephen Rothwell @ 2019-02-23 14:05 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 247 bytes --]
Hi all,
Commit
f68e7927212f ("Revert "powerpc/book3s32: Reorder _PAGE_XXX flags to simplify TLB handling"")
is missing a Signed-off-by from its author and committer.
Reverts are commits as well :-)
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 03/12] PowerPC-83xx: add missing of_node_put after of_device_is_available
From: Julia Lawall @ 2019-02-23 13:20 UTC (permalink / raw)
To: Scott Wood; +Cc: kernel-janitors, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1550928043-14889-1-git-send-email-Julia.Lawall@lip6.fr>
Add an of_node_put when a tested device node is not available.
The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):
// <smpl>
@@
identifier f;
local idexpression e;
expression x;
@@
e = f(...);
... when != of_node_put(e)
when != x = e
when != e = x
when any
if (<+...of_device_is_available(e)...+>) {
... when != of_node_put(e)
(
return e;
|
+ of_node_put(e);
return ...;
)
}
// </smpl>
Fixes: c026c98739c7e ("powerpc/83xx: Do not configure or probe disabled FSL DR USB controllers")
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
arch/powerpc/platforms/83xx/usb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -u -p a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/platforms/83xx/usb.c
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -221,8 +221,10 @@ int mpc837x_usb_cfg(void)
int ret = 0;
np = of_find_compatible_node(NULL, NULL, "fsl-usb2-dr");
- if (!np || !of_device_is_available(np))
+ if (!np || !of_device_is_available(np)) {
+ of_node_put(np);
return -ENODEV;
+ }
prop = of_get_property(np, "phy_type", NULL);
if (!prop || (strcmp(prop, "ulpi") && strcmp(prop, "serial"))) {
^ permalink raw reply
* [PATCH 00/12] add missing of_node_put after of_device_is_available
From: Julia Lawall @ 2019-02-23 13:20 UTC (permalink / raw)
To: linux-amlogic
Cc: linux-fbdev, linux-pm, kernel-janitors, linux-kernel, dri-devel,
linux-crypto, linux-tegra, linux-omap, linuxppc-dev,
linux-arm-kernel
Failure of of_device_is_available implies that the device node
should be put, if it is not used otherwise.
---
arch/arm/mach-omap2/display.c | 4 +++-
arch/powerpc/platforms/83xx/usb.c | 4 +++-
drivers/bus/arm-cci.c | 4 +++-
drivers/cpufreq/armada-8k-cpufreq.c | 4 +++-
drivers/crypto/amcc/crypto4xx_trng.c | 4 +++-
drivers/firmware/psci.c | 4 +++-
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 4 +++-
drivers/gpu/drm/tegra/rgb.c | 4 +++-
drivers/phy/tegra/xusb.c | 4 +++-
drivers/soc/amlogic/meson-gx-socinfo.c | 4 +++-
drivers/tee/optee/core.c | 4 +++-
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c | 4 +++-
12 files changed, 36 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_ssi: remove unsupported formats in i2s master mode
From: Sven Van Asbroeck @ 2019-02-23 13:49 UTC (permalink / raw)
To: Timur Tabi, Nicolin Chen, Xiubo Li
Cc: alsa-devel, linuxppc-dev, Takashi Iwai, Linux Kernel Mailing List,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Fabio Estevam
In-Reply-To: <20190221153550.1932-1-TheSven73@gmail.com>
On Thu, Feb 21, 2019 at 10:35 AM Sven Van Asbroeck <thesven73@gmail.com> wrote:
>
> Fix by constraining the frame bits in i2s master mode
> to 32 * channels. This will filter out those formats
> that the ssi cannot support.
>
Russell King (ARM Linux) informs me that this is not correct, and that
the problem
should be approached differently.
Please remove from consideration if you hadn't done so already.
Thanks :)
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.0-6 tag
From: Michael Ellerman @ 2019-02-23 12:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: aik, linuxppc-dev, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Linus,
Please pull another powerpc fix for 5.0:
The following changes since commit a58007621be33e9f7c7bed5d5ff8ecb914e1044a:
powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present() (2019-02-17 15:24:45 +1100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.0-6
for you to fetch changes up to 8f5b27347e88b171c755562f0090ce40e514fc00:
powerpc/powernv/sriov: Register IOMMU groups for VFs (2019-02-19 11:51:18 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.0 #6
One fix for an oops when using SRIOV, introduced by the recent changes to
support compound IOMMU groups.
Thanks to:
Alexey Kardashevskiy.
- ------------------------------------------------------------------
Alexey Kardashevskiy (1):
powerpc/powernv/sriov: Register IOMMU groups for VFs
arch/powerpc/platforms/powernv/pci-ioda.c | 2 ++
arch/powerpc/platforms/powernv/pci.c | 2 ++
2 files changed, 4 insertions(+)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJccT+TAAoJEFHr6jzI4aWAlYcP/R9XKlvg96FuYEKhJaV3hj1k
QuN3mkaiEia+naAmQrzFgccToUtiMxtQ2Xcg/WryQyOnLKdO1cGuVOrxXSPvTYAE
ESHH7Odd8htt/zzKi/JvHA02puB4u3CmSJu33q6GgDh8LZLyDSjkiQW0tEDB2Oxb
JItN8Q1Swa+On40y2YIQdiKXhhXgHwsH/Mvc5dkNw7N9dCj6kQ908sKFVJ4C7eZI
E2BHnPMOO5hxMHUPI+4CV0J6tKlPoKmJJf8beO9UsrJnMoXO14becJQyqm25jYNg
TPGU3FijIuHolpnBHOJ8EU6c4D8tufC+RDcMprP1o0du8XVekoT3u63LW9xoX8Ff
h3NRDBPeH+D6WtJFl67QTrsVeXaEE23Y2zeYPAoWhBXNzXTJsaiI5dh9N+rYhO/t
t4QLmh2uTVbjHS7KWRVj5m40AlnIJEPGhX8ja8iqRlK2QVbScWmhdbJQRhMa92oe
6/U10sTV9u8Qk6Tf6jRWJdzQJQsHNDx3q1vChmLudQFpJdwc8WzdN2bThgu50rA2
8I1faYBGs2ol3lmjBciRx1KPf5xQUD4NB9K4nmEjG+wlPtLuD1yIl2CGIqapXZoh
brUCNoisrrs7jm6AafauLyid18jZe+uocLiU09OKzpxWZNXulpBwSRYFkjJAr3b0
Q9oTtKpubUI0dhIgOaJp
=lNXB
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] powerpc/64: Simplify __secondary_start paca->kstack handling
From: Michael Ellerman @ 2019-02-23 12:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, matt
In __secondary_start() we load the thread_info of the idle task of the
secondary CPU from current_set[cpu], and then convert it into a stack
pointer before storing that back to paca->kstack.
As pointed out in commit f761622e5943 ("powerpc: Initialise
paca->kstack before early_setup_secondary") it's important that we
initialise paca->kstack before calling the MMU setup code, in
particular slb_initialize(), because it will bolt the SLB entry for
the kstack into the SLB.
However we have already setup paca->kstack in cpu_idle_thread_init(),
since commit 3b5750644b2f ("[POWERPC] Bolt in SLB entry for kernel
stack on secondary cpus") (May 2008).
It's also in cpu_idle_thread_init() that we initialise current_set[cpu]
with the thread_info pointer, so there is no issue of the timing being
different between the two.
Therefore the initialisation of paca->kstack in __setup_secondary() is
completely redundant, so remove it.
This has the added benefit of removing code that runs in real mode,
and is therefore restricted by the RMO, and so opens the way for us to
enable THREAD_INFO_IN_TASK.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/head_64.S | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 4898e9491a1c..3fad8d499767 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -801,21 +801,19 @@ _GLOBAL(pmac_secondary_start)
/* Set thread priority to MEDIUM */
HMT_MEDIUM
- /* Initialize the kernel stack */
- LOAD_REG_ADDR(r3, current_set)
- sldi r28,r24,3 /* get current_set[cpu#] */
- ldx r14,r3,r28
- addi r14,r14,THREAD_SIZE-STACK_FRAME_OVERHEAD
- std r14,PACAKSAVE(r13)
-
- /* Do early setup for that CPU (SLB and hash table pointer) */
+ /*
+ * Do early setup for this CPU, in particular initialising the MMU so we
+ * can turn it on below. This is a call to C, which is OK, we're still
+ * running on the emergency stack.
+ */
bl early_setup_secondary
/*
- * setup the new stack pointer, but *don't* use this until
- * translation is on.
+ * The primary has initialized our kernel stack for us in the paca, grab
+ * it and put it in r1. We must *not* use it until we turn on the MMU
+ * below, because it may not be inside the RMO.
*/
- mr r1, r14
+ ld r1, PACAKSAVE(r13)
/* Clear backchain so we get nice backtraces */
li r7,0
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v16 05/21] powerpc: prep stack walkers for THREAD_INFO_IN_TASK
From: Michael Ellerman @ 2019-02-23 11:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin
In-Reply-To: <20190205113219.17903-6-mpe@ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index ce393df243aa..4ffbb677c9f5 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -2067,6 +2081,9 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
> int curr_frame = 0;
> #endif
>
> + if (!try_get_task_stack(tsk))
> + return;
This needs to be after the NULL check below:
> sp = (unsigned long) stack;
> if (tsk == NULL)
> tsk = current;
Otherwise show_stack(NULL, NULL) blows up :)
I've changed it to:
if (tsk == NULL)
tsk = current;
if (!try_get_task_stack(tsk))
return;
sp = (unsigned long) stack;
if (sp == 0) {
...
cheers
^ permalink raw reply
* [PATCH] tools: testing: selftests: Remove duplicate headers
From: Souptick Joarder @ 2019-02-23 7:09 UTC (permalink / raw)
To: bamv2005, shuah, davem, benh, paulus, mpe, adobriyan,
mathieu.desnoyers, peterz, paulmck, boqun.feng, john.stultz, tglx,
sboyd, akpm
Cc: sabyasachi.linux, netdev, linux-kernel, linux-gpio,
linux-kselftest, linux-fsdevel, linuxppc-dev
Remove duplicate headers which are included twice.
Signed-off-by: Sabyasachi Gupta <sabyasachi.linux@gmail.com>
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
---
tools/testing/selftests/gpio/gpio-mockup-chardev.c | 1 -
tools/testing/selftests/net/udpgso.c | 1 -
tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c | 1 -
tools/testing/selftests/proc/proc-self-syscall.c | 1 -
tools/testing/selftests/rseq/rseq.h | 1 -
tools/testing/selftests/timers/skew_consistency.c | 1 -
tools/testing/selftests/x86/mpx-dig.c | 2 --
7 files changed, 8 deletions(-)
diff --git a/tools/testing/selftests/gpio/gpio-mockup-chardev.c b/tools/testing/selftests/gpio/gpio-mockup-chardev.c
index aaa1e9f..d587c81 100644
--- a/tools/testing/selftests/gpio/gpio-mockup-chardev.c
+++ b/tools/testing/selftests/gpio/gpio-mockup-chardev.c
@@ -12,7 +12,6 @@
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
-#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
diff --git a/tools/testing/selftests/net/udpgso.c b/tools/testing/selftests/net/udpgso.c
index e279051..b8265ee 100644
--- a/tools/testing/selftests/net/udpgso.c
+++ b/tools/testing/selftests/net/udpgso.c
@@ -17,7 +17,6 @@
#include <stdbool.h>
#include <stdlib.h>
#include <stdio.h>
-#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
diff --git a/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c b/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c
index 167135b..af1b802 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/fork_cleanup_test.c
@@ -11,7 +11,6 @@
#include <sys/wait.h>
#include <unistd.h>
#include <setjmp.h>
-#include <signal.h>
#include "ebb.h"
diff --git a/tools/testing/selftests/proc/proc-self-syscall.c b/tools/testing/selftests/proc/proc-self-syscall.c
index 5ab5f48..3a4fec3 100644
--- a/tools/testing/selftests/proc/proc-self-syscall.c
+++ b/tools/testing/selftests/proc/proc-self-syscall.c
@@ -20,7 +20,6 @@
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
-#include <unistd.h>
#include <string.h>
#include <stdio.h>
diff --git a/tools/testing/selftests/rseq/rseq.h b/tools/testing/selftests/rseq/rseq.h
index c72eb70..6c1126e7 100644
--- a/tools/testing/selftests/rseq/rseq.h
+++ b/tools/testing/selftests/rseq/rseq.h
@@ -16,7 +16,6 @@
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
-#include <sched.h>
#include <linux/rseq.h>
/*
diff --git a/tools/testing/selftests/timers/skew_consistency.c b/tools/testing/selftests/timers/skew_consistency.c
index 022b711..8066be9 100644
--- a/tools/testing/selftests/timers/skew_consistency.c
+++ b/tools/testing/selftests/timers/skew_consistency.c
@@ -32,7 +32,6 @@
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
-#include <stdlib.h>
#include <string.h>
#include <sys/wait.h>
#include "../kselftest.h"
diff --git a/tools/testing/selftests/x86/mpx-dig.c b/tools/testing/selftests/x86/mpx-dig.c
index c13607e..880fbf6 100644
--- a/tools/testing/selftests/x86/mpx-dig.c
+++ b/tools/testing/selftests/x86/mpx-dig.c
@@ -8,9 +8,7 @@
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
-#include <sys/types.h>
#include <sys/stat.h>
-#include <unistd.h>
#include <sys/mman.h>
#include <string.h>
#include <fcntl.h>
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] powerpc/kvm: Save and restore AMR instead of zeroing
From: Michael Ellerman @ 2019-02-23 3:16 UTC (permalink / raw)
To: Sasha Levin, Sasha Levin, Russell Currey, kvm-ppc; +Cc: linuxppc-dev, stable
In-Reply-To: <20190222152432.A27CA2070D@mail.kernel.org>
Sasha Levin <sashal@kernel.org> writes:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: cf43d3b26452 powerpc: Enable pkey subsystem.
>
> The bot has tested the following trees: v4.20.11, v4.19.24.
>
> v4.19.24: Failed to apply! Possible dependencies:
> 41f4e631daf8 ("KVM: PPC: Book3S HV: Extract PMU save/restore operations as C-callable functions")
> 95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests")
> d24ea8a7336a ("KVM: PPC: Book3S: Simplify external interrupt handling")
> df709a296ef7 ("KVM: PPC: Book3S HV: Simplify real-mode interrupt handling")
> f7035ce9f1df ("KVM: PPC: Book3S HV: Move interrupt delivery on guest entry to C code")
>
>
> How should we proceed with this patch?
Ignore it. The patch needs more work.
cheers
^ permalink raw reply
* [PATCH v2] powerpc/kvm: Save and restore host AMR/IAMR/UAMOR
From: Michael Ellerman @ 2019-02-23 3:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, kvm-ppc
When the hash MMU is active the AMR, IAMR and UAMOR are used for
pkeys. The AMR is directly writable by user space, and the UAMOR masks
those writes, meaning both registers are effectively user register
state. The IAMR is used to create an execute only key.
Also we must maintain the value of at least the AMR when running in
process context, so that any memory accesses done by the kernel on
behalf of the process are correctly controlled by the AMR.
Although we are correctly switching all registers when going into a
guest, on returning to the host we just write 0 into all regs, except
on Power9 where we restore the IAMR correctly.
This could be observed by a user process if it writes the AMR, then
runs a guest and we then return immediately to it without
rescheduling. Because we have written 0 to the AMR that would have the
effect of granting read/write permission to pages that the process was
trying to protect.
In addition, when using the Radix MMU, the AMR can prevent inadvertent
kernel access to userspace data, writing 0 to the AMR disables that
protection.
So save and restore AMR, IAMR and UAMOR.
Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem")
Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Paul Mackerras <paulus@ozlabs.org>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 26 ++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
v2: Restore AMR, UAMOR and IAMR.
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index f24f6a2f8eb5..25043b50cb30 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -58,6 +58,8 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
#define STACK_SLOT_DAWR (SFS-56)
#define STACK_SLOT_DAWRX (SFS-64)
#define STACK_SLOT_HFSCR (SFS-72)
+#define STACK_SLOT_AMR (SFS-80)
+#define STACK_SLOT_UAMOR (SFS-88)
/* the following is used by the P9 short path */
#define STACK_SLOT_NVGPRS (SFS-152) /* 18 gprs */
@@ -726,11 +728,9 @@ BEGIN_FTR_SECTION
mfspr r5, SPRN_TIDR
mfspr r6, SPRN_PSSCR
mfspr r7, SPRN_PID
- mfspr r8, SPRN_IAMR
std r5, STACK_SLOT_TID(r1)
std r6, STACK_SLOT_PSSCR(r1)
std r7, STACK_SLOT_PID(r1)
- std r8, STACK_SLOT_IAMR(r1)
mfspr r5, SPRN_HFSCR
std r5, STACK_SLOT_HFSCR(r1)
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
@@ -738,11 +738,18 @@ BEGIN_FTR_SECTION
mfspr r5, SPRN_CIABR
mfspr r6, SPRN_DAWR
mfspr r7, SPRN_DAWRX
+ mfspr r8, SPRN_IAMR
std r5, STACK_SLOT_CIABR(r1)
std r6, STACK_SLOT_DAWR(r1)
std r7, STACK_SLOT_DAWRX(r1)
+ std r8, STACK_SLOT_IAMR(r1)
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
+ mfspr r5, SPRN_AMR
+ std r5, STACK_SLOT_AMR(r1)
+ mfspr r6, SPRN_UAMOR
+ std r6, STACK_SLOT_UAMOR(r1)
+
BEGIN_FTR_SECTION
/* Set partition DABR */
/* Do this before re-enabling PMU to avoid P7 DABR corruption bug */
@@ -1631,22 +1638,25 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_300)
mtspr SPRN_PSPB, r0
mtspr SPRN_WORT, r0
BEGIN_FTR_SECTION
- mtspr SPRN_IAMR, r0
mtspr SPRN_TCSCR, r0
/* Set MMCRS to 1<<31 to freeze and disable the SPMC counters */
li r0, 1
sldi r0, r0, 31
mtspr SPRN_MMCRS, r0
END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_300)
-8:
- /* Save and reset AMR and UAMOR before turning on the MMU */
+ /* Save and restore AMR, IAMR and UAMOR before turning on the MMU */
+ ld r8, STACK_SLOT_IAMR(r1)
+ mtspr SPRN_IAMR, r8
+
+8: /* Power7 jumps back in here */
mfspr r5,SPRN_AMR
mfspr r6,SPRN_UAMOR
std r5,VCPU_AMR(r9)
std r6,VCPU_UAMOR(r9)
- li r6,0
- mtspr SPRN_AMR,r6
+ ld r5,STACK_SLOT_AMR(r1)
+ ld r6,STACK_SLOT_UAMOR(r1)
+ mtspr SPRN_AMR, r5
mtspr SPRN_UAMOR, r6
/* Switch DSCR back to host value */
@@ -1746,11 +1756,9 @@ BEGIN_FTR_SECTION
ld r5, STACK_SLOT_TID(r1)
ld r6, STACK_SLOT_PSSCR(r1)
ld r7, STACK_SLOT_PID(r1)
- ld r8, STACK_SLOT_IAMR(r1)
mtspr SPRN_TIDR, r5
mtspr SPRN_PSSCR, r6
mtspr SPRN_PID, r7
- mtspr SPRN_IAMR, r8
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
#ifdef CONFIG_PPC_RADIX_MMU
--
2.20.1
^ permalink raw reply related
* [PATCH v2] powerpc/pseries: Only wait for dying CPU after call to rtas_stop_self()
From: Thiago Jung Bauermann @ 2019-02-22 22:57 UTC (permalink / raw)
To: linuxppc-dev
Cc: Gautham R Shenoy, linux-kernel, Michael Bringmann, Tyrel Datwyler,
Thiago Jung Bauermann
When testing DLPAR CPU add/remove on a system under stress,
pseries_cpu_die() doesn't wait long enough for a CPU to die:
[ 446.983944] cpu 148 (hwid 148) Ready to die...
[ 446.984062] cpu 149 (hwid 149) Ready to die...
[ 446.993518] cpu 150 (hwid 150) Ready to die...
[ 446.993543] Querying DEAD? cpu 150 (150) shows 2
[ 446.994098] cpu 151 (hwid 151) Ready to die...
[ 447.133726] cpu 136 (hwid 136) Ready to die...
[ 447.403532] cpu 137 (hwid 137) Ready to die...
[ 447.403772] cpu 138 (hwid 138) Ready to die...
[ 447.403839] cpu 139 (hwid 139) Ready to die...
[ 447.403887] cpu 140 (hwid 140) Ready to die...
[ 447.403937] cpu 141 (hwid 141) Ready to die...
[ 447.403979] cpu 142 (hwid 142) Ready to die...
[ 447.404038] cpu 143 (hwid 143) Ready to die...
[ 447.513546] cpu 128 (hwid 128) Ready to die...
[ 447.693533] cpu 129 (hwid 129) Ready to die...
[ 447.693999] cpu 130 (hwid 130) Ready to die...
[ 447.703530] cpu 131 (hwid 131) Ready to die...
[ 447.704087] Querying DEAD? cpu 132 (132) shows 2
[ 447.704102] cpu 132 (hwid 132) Ready to die...
[ 447.713534] cpu 133 (hwid 133) Ready to die...
[ 447.714064] Querying DEAD? cpu 134 (134) shows 2
This is a race between one CPU stopping and another one calling
pseries_cpu_die() to wait for it to stop. That function does a short busy
loop calling RTAS query-cpu-stopped-state on the stopping CPU to verify
that it is stopped, but I think there's a lot for the stopping CPU to do
which may take longer than this loop allows.
As can be seen in the dmesg right before or after the "Querying DEAD?"
messages, if pseries_cpu_die() waited a little longer it would have seen
the CPU in the stopped state.
I see two cases that can be causing this race:
1. It's possible that CPU 134 was inactive at the time it was unplugged. In
that case, dlpar_offline_cpu() calls H_PROD on that CPU and immediately
calls pseries_cpu_die(). Meanwhile, the prodded CPU activates and start
the process of stopping itself. It's possible that the busy loop is not
long enough to allow for the CPU to wake up and complete the stopping
process.
2. If CPU 134 was online at the time it was unplugged, it would have gone
through the new CPU hotplug state machine in kernel/cpu.c that was
introduced in v4.6 to get itself stopped. It's possible that the busy
loop in pseries_cpu_die() was long enough for the older hotplug code but
not for the new hotplug state machine.
I don't know if this race condition has any ill effects, but we can make
the race a lot more even if we only start querying if the CPU is stopped
when the stopping CPU is close to call rtas_stop_self().
Since pseries_mach_cpu_die() sets the CPU current state to offline almost
immediately before calling rtas_stop_self(), we use that as a signal that
it is either already stopped or very close to that point, and we can start
the busy loop.
As suggested by Michael Ellerman, this patch also changes the busy loop to
wait for a fixed amount of wall time.
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
I tried to estimate good amounts for the timeout and loop delays, but
I'm not sure how reasonable my numbers are. The busy loops will wait for
100 µs between each try, and spin_event_timeout() will timeout after
100 ms. I'll be happy to change these values if you have better
suggestions.
Gautham was able to test this patch and it solved the race condition.
v1 was a cruder patch which just increased the number of loops:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-February/153734.html
v1 also mentioned a kernel crash but Gautham narrowed it down to a bug
in RTAS, which is in the process of being fixed.
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 97feb6e79f1a..424146cc752e 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -214,13 +214,21 @@ static void pseries_cpu_die(unsigned int cpu)
msleep(1);
}
} else if (get_preferred_offline_state(cpu) == CPU_STATE_OFFLINE) {
+ /*
+ * If the current state is not offline yet, it means that the
+ * dying CPU (which is in pseries_mach_cpu_die) didn't have a
+ * chance to call rtas_stop_self yet and therefore it's too
+ * early to query if the CPU is stopped.
+ */
+ spin_event_timeout(get_cpu_current_state(cpu) == CPU_STATE_OFFLINE,
+ 100000, 100);
for (tries = 0; tries < 25; tries++) {
cpu_status = smp_query_cpu_stopped(pcpu);
if (cpu_status == QCSS_STOPPED ||
cpu_status == QCSS_HARDWARE_ERROR)
break;
- cpu_relax();
+ udelay(100);
}
}
^ permalink raw reply related
* Re: [PATCH V3 00/10] X86/KVM/Hyper-V: Add HV ept tlb range list flush support in KVM
From: Paolo Bonzini @ 2019-02-22 18:25 UTC (permalink / raw)
To: lantianyu1986
Cc: kvm, rkrcmar, will.deacon, christoffer.dall, hpa, kys, kvmarm,
sashal, sthemmin, x86, linux, michael.h.kelley, mingo,
catalin.marinas, jhogan, linux-mips, Lan Tianyu, marc.zyngier,
haiyangz, kvm-ppc, bp, tglx, linux-arm-kernel, linux-kernel, ralf,
paul.burton, devel, vkuznets, linuxppc-dev
In-Reply-To: <20190222150637.2337-1-Tianyu.Lan@microsoft.com>
On 22/02/19 16:06, lantianyu1986@gmail.com wrote:
> From: Lan Tianyu <Tianyu.Lan@microsoft.com>
>
> This patchset is to introduce hv ept tlb range list flush function
> support in the KVM MMU component. Flushing ept tlbs of several address
> range can be done via single hypercall and new list flush function is
> used in the kvm_mmu_commit_zap_page() and FNAME(sync_page). This patchset
> also adds more hv ept tlb range flush support in more KVM MMU function.
>
> This patchset is based on the fix patch "x86/Hyper-V: Fix definition HV_MAX_FLUSH_REP_COUNT".
> (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1939455.html)
Note that this won't make it in 5.1 unless Linus releases an -rc8.
Otherwise, I'll get to it next week.
Thanks,
Paolo
^ permalink raw reply
* [PATCH v2] powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration
From: Aneesh Kumar K.V @ 2019-02-22 17:25 UTC (permalink / raw)
To: npiggin, benh, paulus, mpe; +Cc: Aneesh Kumar K.V, linuxppc-dev
We added runtime allocation of 16G pages in
commit 4ae279c2c96a ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.")
That was done to enable 16G allocation on PowerNV and KVM config. In case of KVM
config, we mostly would have the entire guest RAM backed by 16G hugetlb pages for
this to work. PAPR do support partial backing of guest RAM with hugepages via
ibm,expected#pages node of memory node in the device tree. This means rest of the
guest RAM won't be backed by 16G contiguous pages in the host and hence a hash page
table insertion can fail in such case.
An example error message will look like
hash-mmu: mm: Hashing failure ! EA=0x7efc00000000 access=0x8000000000000006 current=readback
hash-mmu: trap=0x300 vsid=0x67af789 ssize=1 base psize=14 psize 14 pte=0xc000000400000386
readback[12260]: unhandled signal 7 at 00007efc00000000 nip 00000000100012d0 lr 000000001000127c code 2
This patch address that by preventing runtime allocation of 16G hugepages in
LPAR config. To allocate 16G hugetlb one need to kernel command line
hugepagesz=16G hugepages=<number of 16G pages>
With radix translation mode we don't run into this issue.
This change will prevent runtime allocation of 16G hugetlb pages on kvm with
hash translation mode. However, with the current upstream it was observed that
16G hugetlbfs backed guest doesn't boot at all.
We observe boot failure with the below message.
[131354.647546] KVM: map_vrma at 0 failed, ret=-4
That means this patch is not resulting in an observable regression. Once we fix
the boot issue with 16G hugetlb backed memory, we need to use ibm,expected#pages
memory node attribute to indicate 16G page reservation to the guest. This will
also enable partial backing of guest RAM with 16G pages.
Fixes: 4ae279c2c96a ("powerpc/mm/hugetlb: Allow runtime allocation of 16G.")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
Changes from V1:
* update commit message to indicate kvm failure
arch/powerpc/include/asm/book3s/64/hugetlb.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/hugetlb.h b/arch/powerpc/include/asm/book3s/64/hugetlb.h
index 5b0177733994..cd3f2ae0e1e4 100644
--- a/arch/powerpc/include/asm/book3s/64/hugetlb.h
+++ b/arch/powerpc/include/asm/book3s/64/hugetlb.h
@@ -35,6 +35,13 @@ static inline int hstate_get_psize(struct hstate *hstate)
#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE
static inline bool gigantic_page_supported(void)
{
+ /*
+ * We used gigantic page reservation with hypervisor assist in some case.
+ * We cannot use runtime allocation of gigantic pages in those platforms
+ * This is hash translation mode LPARs.
+ */
+ if (firmware_has_feature(FW_FEATURE_LPAR) && !radix_enabled())
+ return false;
return true;
}
#endif
--
2.20.1
^ permalink raw reply related
* RE: [PATCH V3 1/10] X86/Hyper-V: Add parameter offset for hyperv_fill_flush_guest_mapping_list()
From: Stephen Hemminger @ 2019-02-22 17:08 UTC (permalink / raw)
To: lantianyu1986@gmail.com
Cc: kvm@vger.kernel.org, rkrcmar@redhat.com, catalin.marinas@arm.com,
will.deacon@arm.com, linux-kernel@vger.kernel.org, hpa@zytor.com,
KY Srinivasan, kvmarm@lists.cs.columbia.edu, sashal@kernel.org,
x86@kernel.org, linux@armlinux.org.uk, mingo@redhat.com,
jhogan@kernel.org, linux-mips@vger.kernel.org, Tianyu Lan,
marc.zyngier@arm.com, Haiyang Zhang, kvm-ppc@vger.kernel.org,
bp@alien8.de, devel@linuxdriverproject.org, tglx@linutronix.de,
Michael Kelley, linux-arm-kernel@lists.infradead.org,
christoffer.dall@arm.com, ralf@linux-mips.org,
paul.burton@mips.com, pbonzini@redhat.com, vkuznets,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20190222150637.2337-2-Tianyu.Lan@microsoft.com>
int hyperv_fill_flush_guest_mapping_list(
struct hv_guest_mapping_flush_list *flush,
- u64 start_gfn, u64 pages)
+ int offset, u64 start_gfn, u64 pages)
{
u64 cur = start_gfn;
u64 additional_pages;
- int gpa_n = 0;
+ int gpa_n = offset;
do {
/*
Do you mean to support negative offsets here? Maybe unsigned would be better?
^ permalink raw reply
* Re: [PATCH] powerpc/kvm: Save and restore AMR instead of zeroing
From: Sasha Levin @ 2019-02-22 15:24 UTC (permalink / raw)
To: Sasha Levin, Russell Currey, kvm-ppc; +Cc: linuxppc-dev, stable
In-Reply-To: <20190220045958.14966-1-ruscur@russell.cc>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: cf43d3b26452 powerpc: Enable pkey subsystem.
The bot has tested the following trees: v4.20.11, v4.19.24.
v4.19.24: Failed to apply! Possible dependencies:
41f4e631daf8 ("KVM: PPC: Book3S HV: Extract PMU save/restore operations as C-callable functions")
95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests")
d24ea8a7336a ("KVM: PPC: Book3S: Simplify external interrupt handling")
df709a296ef7 ("KVM: PPC: Book3S HV: Simplify real-mode interrupt handling")
f7035ce9f1df ("KVM: PPC: Book3S HV: Move interrupt delivery on guest entry to C code")
How should we proceed with this patch?
--
Thanks,
Sasha
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox