* Re: [PATCH] powerpc/64s: Remove MSR_RI optimisation in system_call_exit()
From: Michael Ellerman @ 2019-02-04 12:15 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <1548232157.y0q1xpn4sp.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Michael Ellerman's on January 17, 2019 9:35 pm:
>> Currently in system_call_exit() we have an optimisation where we
>> disable MSR_RI (recoverable interrupt) and MSR_EE (external interrupt
>> enable) in a single mtmsrd instruction.
>>
>> Unfortunately this will no longer work with THREAD_INFO_IN_TASK,
>> because then the load of TI_FLAGS might fault and faulting with MSR_RI
>> clear is treated as an unrecoverable exception which leads to a
>> panic().
>>
>> So change the code to only clear MSR_EE prior to loading TI_FLAGS,
>> leaving the clear of MSR_RI until later. We have some latitude in
>> where do the clear of MSR_RI. A bit of experimentation has shown that
>> this location gives the least slow down.
>>
>> This still causes a noticeable slow down in our null_syscall
>> performance. On a Power9 DD2.2:
>>
>> Before After Delta Delta %
>> 955 cycles 999 cycles -44 -4.6%
>>
>> On the plus side this does simplify the code somewhat, because we
>> don't have to reenable MSR_RI on the restore_math() or
>> syscall_exit_work() paths which was necessitated previously by the
>> optimisation.
>>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
>
> But only because spectre and meltdown broke my spirit.
😭😭😭😭😭😭😭😭😭😭
Thanks for reviewing it anyway.
cheers
^ permalink raw reply
* Re: use generic DMA mapping code in powerpc V4
From: Christian Zigotzky @ 2019-02-04 12:13 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev
In-Reply-To: <20190204075616.GA5408@lst.de>
On 04 February 2019 at 08:56AM, Christoph Hellwig wrote:
> On Sun, Feb 03, 2019 at 05:49:02PM +0100, Christian Zigotzky wrote:
>> OK, next step: b50f42f0fe12965ead395c76bcb6a14f00cdf65b (powerpc/dma: use
>> the dma_direct mapping routines)
>>
>> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>>
>> git checkout b50f42f0fe12965ead395c76bcb6a14f00cdf65b
>>
>> Results: The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet
>> doesn't work.
> Are there any interesting messages in the boot log? Can you send me
> the dmesg?
>
Here you are: http://www.xenosoft.de/dmesg_X1000_with_DMA_updates.txt
-- Christian
^ permalink raw reply
* Re: [PATCH 06/19] KVM: PPC: Book3S HV: add a GET_ESB_FD control to the XIVE native device
From: Cédric Le Goater @ 2019-02-04 11:30 UTC (permalink / raw)
To: David Gibson; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190204044531.GB1927@umbus.fritz.box>
On 2/4/19 5:45 AM, David Gibson wrote:
> On Mon, Jan 07, 2019 at 07:43:18PM +0100, Cédric Le Goater wrote:
>> 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 <clg@kaod.org>
>> ---
>> arch/powerpc/include/uapi/asm/kvm.h | 4 ++
>> arch/powerpc/kvm/book3s_xive_native.c | 97 +++++++++++++++++++++++++++
>> 2 files changed, 101 insertions(+)
>>
>> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
>> index 8c876c166ef2..6bb61ba141c2 100644
>> --- a/arch/powerpc/include/uapi/asm/kvm.h
>> +++ b/arch/powerpc/include/uapi/asm/kvm.h
>> @@ -675,4 +675,8 @@ 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
>> +#define KVM_DEV_XIVE_GET_ESB_FD 1
>
> Introducing a new FD for ESB and TIMA seems overkill. Can't you get
> to both with an mmap() directly on the xive device fd? Using the
> offset to distinguish which one to map, obviously.
The page offset would define some sort of user API. It seems feasible.
But I am not sure this would be practical in the future if we need to
tune the length.
The TIMA has two pages that can be exposed at guest level for interrupt
management : the OS and the USER page. That should be OK.
But we might want to map only portions of the interrupt ESB space, for
PCI passthrough for instance as Paul proposed. I am still looking at that.
Thanks,
C.
>> #endif /* __LINUX_KVM_POWERPC_H */
>> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
>> index 115143e76c45..e20081f0c8d4 100644
>> --- a/arch/powerpc/kvm/book3s_xive_native.c
>> +++ b/arch/powerpc/kvm/book3s_xive_native.c
>> @@ -153,6 +153,85 @@ int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev,
>> return rc;
>> }
>>
>> +static int xive_native_esb_fault(struct vm_fault *vmf)
>> +{
>> + struct vm_area_struct *vma = vmf->vma;
>> + struct kvmppc_xive *xive = vma->vm_file->private_data;
>> + struct kvmppc_xive_src_block *sb;
>> + struct kvmppc_xive_irq_state *state;
>> + struct xive_irq_data *xd;
>> + u32 hw_num;
>> + u16 src;
>> + u64 page;
>> + unsigned long irq;
>> +
>> + /*
>> + * Linux/KVM uses a two pages ESB setting, one for trigger and
>> + * one for EOI
>> + */
>> + irq = vmf->pgoff / 2;
>> +
>> + sb = kvmppc_xive_find_source(xive, irq, &src);
>> + if (!sb) {
>> + pr_err("%s: source %lx not found !\n", __func__, irq);
>> + return VM_FAULT_SIGBUS;
>> + }
>> +
>> + state = &sb->irq_state[src];
>> + kvmppc_xive_select_irq(state, &hw_num, &xd);
>> +
>> + arch_spin_lock(&sb->lock);
>> +
>> + /*
>> + * first/even page is for trigger
>> + * second/odd page is for EOI and management.
>> + */
>> + page = vmf->pgoff % 2 ? xd->eoi_page : xd->trig_page;
>> + arch_spin_unlock(&sb->lock);
>> +
>> + if (!page) {
>> + pr_err("%s: acessing invalid ESB page for source %lx !\n",
>> + __func__, irq);
>> + return VM_FAULT_SIGBUS;
>> + }
>> +
>> + vmf_insert_pfn(vma, vmf->address, page >> PAGE_SHIFT);
>> + return VM_FAULT_NOPAGE;
>> +}
>> +
>> +static const struct vm_operations_struct xive_native_esb_vmops = {
>> + .fault = xive_native_esb_fault,
>> +};
>> +
>> +static int xive_native_esb_mmap(struct file *file, struct vm_area_struct *vma)
>> +{
>> + /* There are two ESB pages (trigger and EOI) per IRQ */
>> + if (vma_pages(vma) + vma->vm_pgoff > KVMPPC_XIVE_NR_IRQS * 2)
>> + return -EINVAL;
>> +
>> + vma->vm_flags |= VM_IO | VM_PFNMAP;
>> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>> + vma->vm_ops = &xive_native_esb_vmops;
>> + return 0;
>> +}
>> +
>> +static const struct file_operations xive_native_esb_fops = {
>> + .mmap = xive_native_esb_mmap,
>> +};
>> +
>> +static int kvmppc_xive_native_get_esb_fd(struct kvmppc_xive *xive, u64 addr)
>> +{
>> + u64 __user *ubufp = (u64 __user *) addr;
>> + int ret;
>> +
>> + ret = anon_inode_getfd("[xive-esb]", &xive_native_esb_fops, xive,
>> + O_RDWR | O_CLOEXEC);
>> + if (ret < 0)
>> + return ret;
>> +
>> + return put_user(ret, ubufp);
>> +}
>> +
>> static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
>> struct kvm_device_attr *attr)
>> {
>> @@ -162,12 +241,30 @@ static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
>> static int kvmppc_xive_native_get_attr(struct kvm_device *dev,
>> struct kvm_device_attr *attr)
>> {
>> + struct kvmppc_xive *xive = dev->private;
>> +
>> + switch (attr->group) {
>> + case KVM_DEV_XIVE_GRP_CTRL:
>> + switch (attr->attr) {
>> + case KVM_DEV_XIVE_GET_ESB_FD:
>> + return kvmppc_xive_native_get_esb_fd(xive, attr->addr);
>> + }
>> + break;
>> + }
>> 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:
>> + switch (attr->attr) {
>> + case KVM_DEV_XIVE_GET_ESB_FD:
>> + return 0;
>> + }
>> + break;
>> + }
>> return -ENXIO;
>> }
>>
>
^ permalink raw reply
* Re: [PATCH 05/19] KVM: PPC: Book3S HV: add a new KVM device for the XIVE native exploitation mode
From: Cédric Le Goater @ 2019-02-04 11:19 UTC (permalink / raw)
To: David Gibson; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190204042559.GA1927@umbus.fritz.box>
On 2/4/19 5:25 AM, David Gibson wrote:
> On Mon, Jan 07, 2019 at 07:43:17PM +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 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-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> arch/powerpc/include/asm/kvm_host.h | 2 +
>> arch/powerpc/include/asm/kvm_ppc.h | 21 ++
>> arch/powerpc/kvm/book3s_xive.h | 3 +
>> include/uapi/linux/kvm.h | 3 +
>> arch/powerpc/kvm/book3s.c | 7 +-
>> arch/powerpc/kvm/book3s_xive_native.c | 332 ++++++++++++++++++++++++++
>> arch/powerpc/kvm/powerpc.c | 30 +++
>> arch/powerpc/kvm/Makefile | 2 +-
>> 8 files changed, 398 insertions(+), 2 deletions(-)
>> create mode 100644 arch/powerpc/kvm/book3s_xive_native.c
>>
>> diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
>> index 0f98f00da2ea..c522e8274ad9 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;
>>
>> @@ -446,6 +447,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 eb0d79f0ca45..1bb313f238fe 100644
>> --- a/arch/powerpc/include/asm/kvm_ppc.h
>> +++ b/arch/powerpc/include/asm/kvm_ppc.h
>> @@ -591,6 +591,18 @@ 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);
>> +
>> +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);
>> +
>> #else
>> static inline int kvmppc_xive_set_xive(struct kvm *kvm, u32 irq, u32 server,
>> u32 priority) { return -1; }
>> @@ -614,6 +626,15 @@ 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 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) { }
>> +
>> #endif /* CONFIG_KVM_XIVE */
>>
>> /*
>> diff --git a/arch/powerpc/kvm/book3s_xive.h b/arch/powerpc/kvm/book3s_xive.h
>> index 10c4aa5cd010..5f22415520b4 100644
>> --- a/arch/powerpc/kvm/book3s_xive.h
>> +++ b/arch/powerpc/kvm/book3s_xive.h
>> @@ -12,6 +12,9 @@
>> #ifdef CONFIG_KVM_XICS
>> #include "book3s_xics.h"
>>
>> +#define KVMPPC_XIVE_FIRST_IRQ 0
>> +#define KVMPPC_XIVE_NR_IRQS KVMPPC_XICS_NR_IRQS
>> +
>> /*
>> * State for one guest irq source.
>> *
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 6d4ea4b6c922..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
>>
>> @@ -1211,6 +1212,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 bd1a677dd9e4..de7eed191107 100644
>> --- a/arch/powerpc/kvm/book3s.c
>> +++ b/arch/powerpc/kvm/book3s.c
>> @@ -1039,7 +1039,10 @@ static int kvmppc_book3s_init(void)
>> #ifdef CONFIG_KVM_XIVE
>> if (xive_enabled()) {
>> kvmppc_xive_init_module();
>> + kvmppc_xive_native_init_module();
>> kvm_register_device_ops(&kvm_xive_ops, KVM_DEV_TYPE_XICS);
>> + 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 (xive_enabled())
>> + if (xive_enabled()) {
>> 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..115143e76c45
>> --- /dev/null
>> +++ b/arch/powerpc/kvm/book3s_xive_native.c
>> @@ -0,0 +1,332 @@
>> +// 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 void 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 */
>> + 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)
>
> Why do we need both a *vcpu and a cpu number as an integer?
To be in sync with the other similar routines : kvmppc_xics_connect_vcpu()
and kvmppc_xive_connect_vcpu().
But if we consider that this 'cpu' parameter is always in sync with
vcpu->vcpu_id, we could remove it from the KVM ioctl call I suppose.
Should we do the same for the other routines ?
>> +{
>> + 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)
>
> Please use an explicit == / != here so we don't have to remember which
> symbolic value corresponds to 0.
ok. I agree.
Thanks,
C.
>
>> + return -EBUSY;
>> + if (kvmppc_xive_find_server(vcpu->kvm, cpu)) {
>> + 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;
>> + xc->xive = xive;
>> + xc->vcpu = vcpu;
>> + xc->server_num = cpu;
>> + xc->vp_id = xive->vp_base + cpu;
>> + 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)
>> +{
>> + 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)
>> +{
>> + return -ENXIO;
>> +}
>> +
>> +static void kvmppc_xive_native_free(struct kvm_device *dev)
>> +{
>> + struct kvmppc_xive *xive = dev->private;
>> + struct kvm *kvm = xive->kvm;
>> + int i;
>> +
>> + debugfs_remove(xive->dentry);
>> +
>> + pr_devel("Destroying xive native for partition\n");
>> +
>> + if (kvm)
>> + kvm->arch.xive = NULL;
>> +
>> + /* Mask and free interrupts */
>> + for (i = 0; i <= xive->max_sbid; i++) {
>> + if (xive->src_blocks[i])
>> + kvmppc_xive_free_sources(xive->src_blocks[i]);
>> + kfree(xive->src_blocks[i]);
>> + xive->src_blocks[i] = 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 for partition\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 */
>> + 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 */
>> + 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;
>> + 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;
>> +}
>> +
>> +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/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>> index b90a7d154180..01d526e15e9d 100644
>> --- a/arch/powerpc/kvm/powerpc.c
>> +++ b/arch/powerpc/kvm/powerpc.c
>> @@ -566,6 +566,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>> case KVM_CAP_PPC_ENABLE_HCALL:
>> #ifdef CONFIG_KVM_XICS
>> case KVM_CAP_IRQ_XICS:
>> +#endif
>> +#ifdef CONFIG_KVM_XIVE
>> + case KVM_CAP_PPC_IRQ_XIVE:
>> #endif
>> case KVM_CAP_PPC_GET_CPU_CHAR:
>> r = 1;
>> @@ -753,6 +756,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 +1947,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/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 := \
>
^ permalink raw reply
* Re: [PATCH v15 00/13] powerpc: Switch to CONFIG_THREAD_INFO_IN_TASK
From: Michael Ellerman @ 2019-02-04 11:20 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Nicholas Piggin
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1548852242.git.christophe.leroy@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> The purpose of this serie is to activate CONFIG_THREAD_INFO_IN_TASK which
> moves the thread_info into task_struct.
Hi Christophe,
I've taken this series and split some of the patches up a bit more.
I'll just run it through some tests and then post my version.
cheers
> Moving thread_info into task_struct has the following advantages:
> - It protects thread_info from corruption in the case of stack
> overflows.
> - Its address is harder to determine if stack addresses are
> leaked, making a number of attacks more difficult.
>
> Changes in v15:
> - switched patch 1 and 2.
> - resync patch 1 with linux/next. As memblock modifications are now fully merged in
> linux-mm tree, this patch voids as soon as linux-mm gets merged into powerpc/merge branch
> - Fixed build failure on 64le due to call to __save_stack_trace_tsk_reliable() (patch 5)
> - Taken the renaming of THREAD_INFO to TASK_STACK out of the preparation patch to ease review (hence new patch 6)
> - Fixed one place where r11 (physical address of stack) was used instead of r1 to locate
> thread_info, inducing a bug when switching to r2 which is virtual address of current (patch 7)
> - Keeping physical address of current in r2 until MMU translation is reactivated (patch 11)
>
> Changes in v14 (ie since v13):
> - Added in front a fixup patch which conflicts with this serie
> - Added a patch for using try_get_task_stack()/put_task_stack() in stack walkers.
> - Fixed compilation failure in the preparation patch (by moving the modification
> of klp_init_thread_info() to the following patch)
>
> Changes since v12:
> - Patch 1: Taken comment from Mike (re-introduced the 'panic' in case memblock allocation fails in setup_64.c
> - Patch 1: Added alloc_stack() function in setup_32.c to also panic in case of allocation failure.
>
> Changes since v11:
> - Rebased on 81775f5563fa ("Automatic merge of branches 'master', 'next' and 'fixes' into merge")
> - Added a first patch to change memblock allocs to functions returning virtual addrs. This removes
> the memset() which were the only remaining stuff in irq_ctx_init() and exc_lvl_ctx_init() at the end.
> - dropping irq_ctx_init() and exc_lvl_ctx_init() in patch 5 (powerpc: Activate CONFIG_THREAD_INFO_IN_TASK)
> - A few cosmetic changes in commit log and code.
>
> Changes since v10:
> - Rebased on 21622a0d2023 ("Automatic merge of branches 'master', 'next' and 'fixes' into merge")
> ==> Fixed conflict in setup_32.S
>
> Changes since v9:
> - Rebased on 183cbf93be88 ("Automatic merge of branches 'master', 'next' and 'fixes' into merge")
> ==> Fixed conflict on xmon
>
> Changes since v8:
> - Rebased on e589b79e40d9 ("Automatic merge of branches 'master', 'next' and 'fixes' into merge")
> ==> Main impact was conflicts due to commit 9a8dd708d547 ("memblock: rename memblock_alloc{_nid,_try_nid} to memblock_phys_alloc*")
>
> Changes since v7:
> - Rebased on fb6c6ce7907d ("Automatic merge of branches 'master', 'next' and 'fixes' into merge")
>
> Changes since v6:
> - Fixed validate_sp() to exclude NULL sp in 'regain entire stack space' patch (early crash with CONFIG_KMEMLEAK)
>
> Changes since v5:
> - Fixed livepatch_sp setup by using end_of_stack() instead of hardcoding
> - Fixed PPC_BPF_LOAD_CPU() macro
>
> Changes since v4:
> - Fixed a build failure on 32bits SMP when include/generated/asm-offsets.h is not
> already existing, was due to spaces instead of a tab in the Makefile
>
> Changes since RFC v3: (based on Nick's review)
> - Renamed task_size.h to task_size_user64.h to better relate to what it contains.
> - Handling of the isolation of thread_info cpu field inside CONFIG_SMP #ifdefs moved to a separate patch.
> - Removed CURRENT_THREAD_INFO macro completely.
> - Added a guard in asm/smp.h to avoid build failure before _TASK_CPU is defined.
> - Added a patch at the end to rename 'tp' pointers to 'sp' pointers
> - Renamed 'tp' into 'sp' pointers in preparation patch when relevant
> - Fixed a few commit logs
> - Fixed checkpatch report.
>
> Changes since RFC v2:
> - Removed the modification of names in asm-offsets
> - Created a rule in arch/powerpc/Makefile to append the offset of current->cpu in CFLAGS
> - Modified asm/smp.h to use the offset set in CFLAGS
> - Squashed the renaming of THREAD_INFO to TASK_STACK in the preparation patch
> - Moved the modification of current_pt_regs in the patch activating CONFIG_THREAD_INFO_IN_TASK
>
> Changes since RFC v1:
> - Removed the first patch which was modifying header inclusion order in timer
> - Modified some names in asm-offsets to avoid conflicts when including asm-offsets in C files
> - Modified asm/smp.h to avoid having to include linux/sched.h (using asm-offsets instead)
> - Moved some changes from the activation patch to the preparation patch.
>
> Christophe Leroy (13):
> powerpc/irq: use memblock functions returning virtual address
> powerpc/32: Fix CONFIG_VIRT_CPU_ACCOUNTING_NATIVE for 40x/booke
> book3s/64: avoid circular header inclusion in mmu-hash.h
> powerpc: Only use task_struct 'cpu' field on SMP
> powerpc: prep stack walkers for THREAD_INFO_IN_TASK
> powerpc: Rename THREAD_INFO to TASK_STACK
> powerpc: Prepare for moving thread_info into task_struct
> powerpc: Activate CONFIG_THREAD_INFO_IN_TASK
> powerpc: regain entire stack space
> powerpc: 'current_set' is now a table of task_struct pointers
> powerpc/32: Remove CURRENT_THREAD_INFO and rename TI_CPU
> powerpc/64: Remove CURRENT_THREAD_INFO
> powerpc: clean stack pointers naming
>
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/Makefile | 7 ++
> arch/powerpc/include/asm/asm-prototypes.h | 4 +-
> arch/powerpc/include/asm/book3s/64/mmu-hash.h | 2 +-
> arch/powerpc/include/asm/exception-64s.h | 4 +-
> arch/powerpc/include/asm/irq.h | 18 ++--
> arch/powerpc/include/asm/livepatch.h | 6 +-
> arch/powerpc/include/asm/processor.h | 39 +--------
> arch/powerpc/include/asm/ptrace.h | 2 +-
> arch/powerpc/include/asm/reg.h | 2 +-
> arch/powerpc/include/asm/smp.h | 17 +++-
> arch/powerpc/include/asm/task_size_user64.h | 42 +++++++++
> arch/powerpc/include/asm/thread_info.h | 19 -----
> arch/powerpc/kernel/asm-offsets.c | 10 ++-
> arch/powerpc/kernel/entry_32.S | 80 ++++++-----------
> arch/powerpc/kernel/entry_64.S | 12 +--
> arch/powerpc/kernel/epapr_hcalls.S | 5 +-
> arch/powerpc/kernel/exceptions-64e.S | 13 +--
> arch/powerpc/kernel/exceptions-64s.S | 2 +-
> arch/powerpc/kernel/head_32.S | 14 +--
> arch/powerpc/kernel/head_40x.S | 4 +-
> arch/powerpc/kernel/head_44x.S | 8 +-
> arch/powerpc/kernel/head_64.S | 1 +
> arch/powerpc/kernel/head_8xx.S | 2 +-
> arch/powerpc/kernel/head_booke.h | 12 +--
> arch/powerpc/kernel/head_fsl_booke.S | 16 ++--
> arch/powerpc/kernel/idle_6xx.S | 8 +-
> arch/powerpc/kernel/idle_book3e.S | 2 +-
> arch/powerpc/kernel/idle_e500.S | 8 +-
> arch/powerpc/kernel/idle_power4.S | 2 +-
> arch/powerpc/kernel/irq.c | 114 +++----------------------
> arch/powerpc/kernel/kgdb.c | 28 ------
> arch/powerpc/kernel/machine_kexec_64.c | 6 +-
> arch/powerpc/kernel/misc_32.S | 17 ++--
> arch/powerpc/kernel/process.c | 63 ++++++++------
> arch/powerpc/kernel/setup-common.c | 2 +-
> arch/powerpc/kernel/setup_32.c | 26 +++---
> arch/powerpc/kernel/setup_64.c | 51 +++--------
> arch/powerpc/kernel/smp.c | 16 ++--
> arch/powerpc/kernel/stacktrace.c | 29 ++++++-
> arch/powerpc/kernel/trace/ftrace_64_mprofile.S | 6 +-
> arch/powerpc/kvm/book3s_hv_hmi.c | 1 +
> arch/powerpc/mm/hash_low_32.S | 14 ++-
> arch/powerpc/net/bpf_jit32.h | 5 +-
> arch/powerpc/sysdev/6xx-suspend.S | 5 +-
> arch/powerpc/xmon/xmon.c | 2 +-
> 46 files changed, 302 insertions(+), 445 deletions(-)
> create mode 100644 arch/powerpc/include/asm/task_size_user64.h
>
> --
> 2.13.3
^ permalink raw reply
* Re: [PATCH v2] powerpc: drop page_is_ram() and walk_system_ram_range()
From: Michael Ellerman @ 2019-02-04 10:24 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a14aac5408f98cf8ad8723ffa874764ccb42d4d4.1548978750.git.christophe.leroy@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> Since commit c40dd2f76644 ("powerpc: Add System RAM to /proc/iomem")
> it is possible to use the generic walk_system_ram_range() and
> the generic page_is_ram().
>
> To enable the use of walk_system_ram_range() by the IBM EHEA
> ethernet driver, the generic function has to be exported.
I'm not sure if we have a policy on that, but I suspect we'd rather not
add a new export on all arches unless we need to. Especially seeing as
the only user is the EHEA code which is heavily in maintenance mode.
I'll put the export in powerpc code and make sure that builds.
> As powerpc was the only (last?) user of CONFIG_ARCH_HAS_WALK_MEMORY,
> the #ifdef around the generic walk_system_ram_range() has become
> useless and can be dropped.
Yes it was the only user:
a99824f327c7 ("[POWERPC] Add arch-specific walk_memory_remove() for 64-bit powerpc")
I'll update the changelog.
cheers
> Fixes: c40dd2f76644 ("powerpc: Add System RAM to /proc/iomem")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/Kconfig | 3 ---
> arch/powerpc/include/asm/page.h | 1 -
> arch/powerpc/mm/mem.c | 33 ---------------------------------
> kernel/resource.c | 5 +----
> 4 files changed, 1 insertion(+), 41 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 2890d36eb531..f92e6754edf1 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -478,9 +478,6 @@ config ARCH_CPU_PROBE_RELEASE
> config ARCH_ENABLE_MEMORY_HOTPLUG
> def_bool y
>
> -config ARCH_HAS_WALK_MEMORY
> - def_bool y
> -
> config ARCH_ENABLE_MEMORY_HOTREMOVE
> def_bool y
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 5c5ea2413413..aa4497175bd3 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -326,7 +326,6 @@ struct page;
> extern void clear_user_page(void *page, unsigned long vaddr, struct page *pg);
> extern void copy_user_page(void *to, void *from, unsigned long vaddr,
> struct page *p);
> -extern int page_is_ram(unsigned long pfn);
> extern int devmem_is_allowed(unsigned long pfn);
>
> #ifdef CONFIG_PPC_SMLPAR
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 33cc6f676fa6..fa9916c2c662 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -80,11 +80,6 @@ static inline pte_t *virt_to_kpte(unsigned long vaddr)
> #define TOP_ZONE ZONE_NORMAL
> #endif
>
> -int page_is_ram(unsigned long pfn)
> -{
> - return memblock_is_memory(__pfn_to_phys(pfn));
> -}
> -
> pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> unsigned long size, pgprot_t vma_prot)
> {
> @@ -176,34 +171,6 @@ int __meminit arch_remove_memory(int nid, u64 start, u64 size,
> #endif
> #endif /* CONFIG_MEMORY_HOTPLUG */
>
> -/*
> - * walk_memory_resource() needs to make sure there is no holes in a given
> - * memory range. PPC64 does not maintain the memory layout in /proc/iomem.
> - * Instead it maintains it in memblock.memory structures. Walk through the
> - * memory regions, find holes and callback for contiguous regions.
> - */
> -int
> -walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
> - void *arg, int (*func)(unsigned long, unsigned long, void *))
> -{
> - struct memblock_region *reg;
> - unsigned long end_pfn = start_pfn + nr_pages;
> - unsigned long tstart, tend;
> - int ret = -1;
> -
> - for_each_memblock(memory, reg) {
> - tstart = max(start_pfn, memblock_region_memory_base_pfn(reg));
> - tend = min(end_pfn, memblock_region_memory_end_pfn(reg));
> - if (tstart >= tend)
> - continue;
> - ret = (*func)(tstart, tend - tstart, arg);
> - if (ret)
> - break;
> - }
> - return ret;
> -}
> -EXPORT_SYMBOL_GPL(walk_system_ram_range);
> -
> #ifndef CONFIG_NEED_MULTIPLE_NODES
> void __init mem_topology_setup(void)
> {
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 915c02e8e5dd..2e1636041508 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -448,8 +448,6 @@ int walk_mem_res(u64 start, u64 end, void *arg,
> arg, func);
> }
>
> -#if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
> -
> /*
> * This function calls the @func callback against all memory ranges of type
> * System RAM which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
> @@ -480,8 +478,7 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
> }
> return ret;
> }
> -
> -#endif
> +EXPORT_SYMBOL_GPL(walk_system_ram_range);
>
> static int __is_ram(unsigned long pfn, unsigned long nr_pages, void *arg)
> {
> --
> 2.13.3
^ permalink raw reply
* Re: [PATCH 03/19] KVM: PPC: Book3S HV: check the IRQ controller type
From: Cédric Le Goater @ 2019-02-04 10:16 UTC (permalink / raw)
To: David Gibson; +Cc: kvm, kvm-ppc, linuxppc-dev
In-Reply-To: <20190204005056.GC2593@umbus.fritz.box>
On 2/4/19 1:50 AM, David Gibson wrote:
> On Wed, Jan 23, 2019 at 05:24:13PM +0100, Cédric Le Goater wrote:
>> On 1/22/19 5:56 AM, Paul Mackerras wrote:
>>> On Mon, Jan 07, 2019 at 07:43:15PM +0100, Cédric Le Goater wrote:
>>>> 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 <clg@kaod.org>
>>>> ---
>>>> arch/powerpc/kvm/book3s_xive.c | 6 ++++++
>>>> 1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
>>>> index f78d002f0fe0..8a4fa45f07f8 100644
>>>> --- a/arch/powerpc/kvm/book3s_xive.c
>>>> +++ b/arch/powerpc/kvm/book3s_xive.c
>>>> @@ -819,6 +819,9 @@ u64 kvmppc_xive_get_icp(struct kvm_vcpu *vcpu)
>>>> {
>>>> struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
>>>>
>>>> + if (!kvmppc_xics_enabled(vcpu))
>>>> + return -EPERM;
>>>> +
>>>> if (!xc)
>>>> return 0;
>>>>
>>>> @@ -835,6 +838,9 @@ int kvmppc_xive_set_icp(struct kvm_vcpu *vcpu, u64 icpval)
>>>> u8 cppr, mfrr;
>>>> u32 xisr;
>>>>
>>>> + if (!kvmppc_xics_enabled(vcpu))
>>>> + return -EPERM;
>>>> +
>>>> if (!xc || !xive)
>>>> return -ENOENT;
>>>
>>> I can't see how these new checks could ever trigger in the code as it
>>> stands. Is there a way at present?
>>
>> It would require some custom QEMU doing silly things : create the XICS
>> KVM device, and then call kvm_get_one_reg(KVM_REG_PPC_ICP_STATE) or
>> kvm_set_one_reg(icp->cs, KVM_REG_PPC_ICP_STATE) without connecting the
>> vCPU to its presenter.
>>
>> Today, you get a ENOENT.
>
> TBH, ENOENT seems fine to me.
>
>>> Do following patches ever add a path where the new checks could trigger,
>>> or is this just an excess of caution?
>>
>> With the following patches, QEMU could to do something even more silly,
>> which is to mix the interrupt mode interfaces : create a KVM XICS device
>> and call KVM CPU ioctls of the KVM XIVE device, or the opposite.
>
> AFAICT, like above, that won't really differ from calling the XIVE CPU
> ioctl()s when no irqchip is set up at all, and should be covered by
> just a !xive check.
we can drop that patch. It does not bring much.
Thanks,
C.
>
>>
>>> (Your patch description should ideally have answered these questions > for me.)
>>
>> Yes. I also think that I introduced this patch to early in the series.
>> It make more sense when the XICS and the XIVE KVM devices are available.
>>
>> Thanks,
>>
>> C.
>>
>
^ permalink raw reply
* Applied "ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe" to the asoc tree
From: Mark Brown @ 2019-02-04 9:07 UTC (permalink / raw)
To: wen yang
Cc: alsa-devel, Timur Tabi, Xiubo Li, linuxppc-dev, Takashi Iwai,
Liam Girdwood, Jaroslav Kysela, Nicolin Chen, Mark Brown,
Wen Yang, Fabio Estevam, linux-kernel
The patch
ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 11907e9d3533648615db08140e3045b829d2c141 Mon Sep 17 00:00:00 2001
From: wen yang <yellowriver2010@hotmail.com>
Date: Sat, 2 Feb 2019 14:53:16 +0000
Subject: [PATCH] ASoC: fsl-asoc-card: fix object reference leaks in
fsl_asoc_card_probe
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Signed-off-by: Wen Yang <yellowriver2010@hotmil.com>
Cc: Timur Tabi <timur@kernel.org>
Cc: Nicolin Chen <nicoleotsuka@gmail.com>
Cc: Xiubo Li <Xiubo.Lee@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/fsl/fsl-asoc-card.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 81f2fe2c6d23..60f87a0d99f4 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -689,6 +689,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
asrc_fail:
of_node_put(asrc_np);
of_node_put(codec_np);
+ put_device(&cpu_pdev->dev);
fail:
of_node_put(cpu_np);
--
2.20.1
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: soc: fsl: Document Qixis FPGA usage
From: Pankaj Bansal @ 2019-02-04 9:10 UTC (permalink / raw)
To: Leo Li
Cc: Pankaj Bansal, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190204143449.25040-1-pankaj.bansal@nxp.com>
an FPGA-based system controller, called “Qixis”, which
manages several critical system features, including:
• Reset sequencing
• Power supply configuration
• Board configuration
• hardware configuration
The qixis registers are accessible over one or more system-specific
interfaces, typically I2C, JTAG or an embedded processor.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Notes:
V3:
- Added boardname based compatible field in bindings
- Added bindings for MMIO based FPGA
V2:
- No change
.../bindings/soc/fsl/qixis_ctrl.txt | 53 ++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt b/Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt
new file mode 100644
index 000000000000..5d510df14be8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt
@@ -0,0 +1,53 @@
+* QIXIS FPGA block
+
+an FPGA-based system controller, called “Qixis”, which
+manages several critical system features, including:
+• Configuration switch monitoring
+• Power on/off sequencing
+• Reset sequencing
+• Power supply configuration
+• Board configuration
+• hardware configuration
+• Background power data collection (DCM)
+• Fault monitoring
+• RCW bypass SRAM (replace flash RCW with internal RCW) (NOR only)
+• Dedicated functional validation blocks (POSt/IRS, triggered event, and so on)
+• I2C master for remote board control even with no DUT available
+
+The qixis registers are accessible over one or more system-specific interfaces,
+typically I2C, JTAG or an embedded processor.
+
+FPGA connected to I2C:
+Required properties:
+
+ - compatible: should be a board-specific string followed by a string
+ indicating the type of FPGA. Example:
+ "fsl,<board>-fpga", "fsl,fpga-qixis-i2c"
+ - reg : i2c address of the qixis device.
+
+Example (LX2160A-QDS):
+ /* The FPGA node */
+ fpga@66 {
+ compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c";
+ reg = <0x66>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ }
+
+* Freescale on-board FPGA
+
+This is the memory-mapped registers for on board FPGA.
+
+Required properties:
+- compatible: should be a board-specific string followed by a string
+ indicating the type of FPGA. Example:
+ "fsl,<board>-fpga", "fsl,fpga-qixis"
+- reg: should contain the address and the length of the FPGA register set.
+
+Example (LS2080A-RDB):
+
+ cpld@3,0 {
+ compatible = "fsl,ls2080ardb-fpga", "fsl,fpga-qixis";
+ reg = <0x3 0 0x10000>;
+ };
+
--
2.17.1
^ permalink raw reply related
* [PATCH v3 0/2] add qixis driver
From: Pankaj Bansal @ 2019-02-04 9:10 UTC (permalink / raw)
To: Leo Li
Cc: Pankaj Bansal, linuxppc-dev@lists.ozlabs.org, Varun Sethi,
linux-arm-kernel@lists.infradead.org
FPGA on LX2160AQDS/LX2160ARDB connected on I2C bus,
so add qixis driver which is basically an i2c client driver to control FPGA.
Also added platform driver for MMIO based FPGA, like the one available
on LS2088ARDB/LS2088AQDS.
This driver is essential to control MDIO mux multiplexing.
This driver is dependent on below patches:
https://www.mail-archive.com/netdev@vger.kernel.org/msg281274.html
Cc: Varun Sethi <V.Sethi@nxp.com>
---
Notes:
V2:
- https://patchwork.kernel.org/cover/10788341/
V1:
- https://patchwork.kernel.org/cover/10627297/
Pankaj Bansal (2):
dt-bindings: soc: fsl: Document Qixis FPGA usage
drivers: soc: fsl: add qixis driver
.../bindings/soc/fsl/qixis_ctrl.txt | 53 +++++
drivers/soc/fsl/Kconfig | 11 +
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/qixis_ctrl.c | 207 ++++++++++++++++++
4 files changed, 272 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/fsl/qixis_ctrl.txt
create mode 100644 drivers/soc/fsl/qixis_ctrl.c
--
2.17.1
^ permalink raw reply
* [PATCH v3 2/2] drivers: soc: fsl: add qixis driver
From: Pankaj Bansal @ 2019-02-04 9:10 UTC (permalink / raw)
To: Leo Li
Cc: Pankaj Bansal, linuxppc-dev@lists.ozlabs.org, Wang Dongsheng,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190204143449.25040-1-pankaj.bansal@nxp.com>
FPGA on LX2160AQDS/LX2160ARDB connected on I2C bus, so add qixis
driver which is basically an i2c client driver to control FPGA.
Also added platform driver for MMIO based FPGA, like the one available
on LS2088ARDB/LS2088AQDS.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Notes:
V3:
- Add MMIO based FPGA driver
V2:
- Modify the driver to not create platform devices corresponding to subnodes.
because the subnodes are not actual devices.
- Use mdio_mux_regmap_init/mdio_mux_regmap_uninit
- Remove header file from include folder, as no qixis api is called from outside
- Add regmap_exit in driver's remove function
Dendencies:
- https://www.mail-archive.com/netdev@vger.kernel.org/msg281274.html
drivers/soc/fsl/Kconfig | 11 ++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/qixis_ctrl.c | 207 +++++++++++++++++++++++++++++++++
3 files changed, 219 insertions(+)
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index 8f80e8bbf29e..75993be04e42 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -28,4 +28,15 @@ config FSL_MC_DPIO
other DPAA2 objects. This driver does not expose the DPIO
objects individually, but groups them under a service layer
API.
+
+config FSL_QIXIS
+ tristate "QIXIS system controller driver"
+ depends on OF
+ select REGMAP_I2C
+ select REGMAP_MMIO
+ default n
+ help
+ Say y here to enable QIXIS system controller api. The qixis driver
+ provides FPGA functions to control system.
+
endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 803ef1bfb5ff..47e0cfc66ca4 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -5,5 +5,6 @@
obj-$(CONFIG_FSL_DPAA) += qbman/
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_QIXIS) += qixis_ctrl.o
obj-$(CONFIG_FSL_GUTS) += guts.o
obj-$(CONFIG_FSL_MC_DPIO) += dpio/
diff --git a/drivers/soc/fsl/qixis_ctrl.c b/drivers/soc/fsl/qixis_ctrl.c
new file mode 100644
index 000000000000..36a3e1abc465
--- /dev/null
+++ b/drivers/soc/fsl/qixis_ctrl.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/* Freescale QIXIS system controller driver.
+ *
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ * Copyright 2018-2019 NXP
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mdio-mux.h>
+
+/* QIXIS MAP */
+struct fsl_qixis_regs {
+ u8 id; /* Identification Registers */
+ u8 version; /* Version Register */
+ u8 qixis_ver; /* QIXIS Version Register */
+ u8 reserved1[0x1f];
+};
+
+struct mdio_mux_data {
+ void *data;
+ struct list_head link;
+};
+
+struct qixis_priv {
+ struct regmap *regmap;
+ struct list_head mdio_mux_list;
+};
+
+static struct regmap_config qixis_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+static int fsl_qixis_mdio_mux_init(struct device *dev, struct qixis_priv *priv)
+{
+ struct device_node *child;
+ struct mdio_mux_data *mux_data;
+ int ret;
+
+ INIT_LIST_HEAD(&priv->mdio_mux_list);
+ for_each_child_of_node(dev->of_node, child) {
+ if (!of_node_name_prefix(child, "mdio-mux"))
+ continue;
+
+ mux_data = devm_kzalloc(dev, sizeof(struct mdio_mux_data),
+ GFP_KERNEL);
+ if (!mux_data)
+ return -ENOMEM;
+ ret = mdio_mux_regmap_init(dev, child, &mux_data->data);
+ if (ret)
+ return ret;
+ list_add(&mux_data->link, &priv->mdio_mux_list);
+ }
+
+ return 0;
+}
+
+static int fsl_qixis_mdio_mux_uninit(struct qixis_priv *priv)
+{
+ struct list_head *pos;
+ struct mdio_mux_data *mux_data;
+
+ list_for_each(pos, &priv->mdio_mux_list) {
+ mux_data = list_entry(pos, struct mdio_mux_data, link);
+ mdio_mux_regmap_uninit(mux_data->data);
+ }
+
+ return 0;
+}
+
+static int fsl_qixis_probe(struct platform_device *pdev)
+{
+ static struct fsl_qixis_regs __iomem *qixis;
+ struct qixis_priv *priv;
+ int ret;
+ u32 qver;
+
+ qixis = of_iomap(pdev->dev.of_node, 0);
+ if (IS_ERR_OR_NULL(qixis)) {
+ pr_err("%s: Could not map qixis registers\n", __func__);
+ return -ENODEV;
+ }
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(struct qixis_priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->regmap = devm_regmap_init_mmio(&pdev->dev, qixis,
+ &qixis_regmap_config);
+ regmap_read(priv->regmap, offsetof(struct fsl_qixis_regs, qixis_ver),
+ &qver);
+ pr_info("Freescale QIXIS Version: 0x%08x\n", qver);
+
+ ret = fsl_qixis_mdio_mux_init(&pdev->dev, priv);
+ if (ret)
+ goto error;
+
+ platform_set_drvdata(pdev, priv);
+
+ return 0;
+error:
+ regmap_exit(priv->regmap);
+
+ return ret;
+}
+
+static int fsl_qixis_remove(struct platform_device *pdev)
+{
+ struct qixis_priv *priv;
+
+ priv = platform_get_drvdata(pdev);
+ fsl_qixis_mdio_mux_uninit(priv);
+ regmap_exit(priv->regmap);
+
+ return 0;
+}
+
+static const struct of_device_id fsl_qixis_of_match[] = {
+ { .compatible = "fsl,fpga-qixis", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, fsl_qixis_of_match);
+
+static struct platform_driver fsl_qixis_driver = {
+ .driver = {
+ .name = "qixis_ctrl",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(fsl_qixis_of_match),
+ },
+ .probe = fsl_qixis_probe,
+ .remove = fsl_qixis_remove,
+};
+module_platform_driver(fsl_qixis_driver);
+
+static int fsl_qixis_i2c_probe(struct i2c_client *client)
+{
+ struct qixis_priv *priv;
+ int ret;
+ u32 qver;
+
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -EOPNOTSUPP;
+
+ priv = devm_kzalloc(&client->dev, sizeof(struct qixis_priv),
+ GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->regmap = regmap_init_i2c(client, &qixis_regmap_config);
+ regmap_read(priv->regmap, offsetof(struct fsl_qixis_regs, qixis_ver),
+ &qver);
+ pr_info("Freescale QIXIS Version: 0x%08x\n", qver);
+
+ ret = fsl_qixis_mdio_mux_init(&client->dev, priv);
+ if (ret)
+ goto error;
+
+ i2c_set_clientdata(client, priv);
+
+ return 0;
+error:
+ regmap_exit(priv->regmap);
+
+ return ret;
+}
+
+static int fsl_qixis_i2c_remove(struct i2c_client *client)
+{
+ struct qixis_priv *priv;
+
+ priv = i2c_get_clientdata(client);
+ fsl_qixis_mdio_mux_uninit(priv);
+ regmap_exit(priv->regmap);
+
+ return 0;
+}
+
+static const struct of_device_id fsl_qixis_i2c_of_match[] = {
+ { .compatible = "fsl,fpga-qixis-i2c" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, fsl_qixis_i2c_of_match);
+
+static struct i2c_driver fsl_qixis_i2c_driver = {
+ .driver = {
+ .name = "qixis_ctrl",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(fsl_qixis_i2c_of_match),
+ },
+ .probe_new = fsl_qixis_i2c_probe,
+ .remove = fsl_qixis_i2c_remove,
+};
+module_i2c_driver(fsl_qixis_i2c_driver);
+
+MODULE_AUTHOR("Wang Dongsheng <dongsheng.wang@freescale.com>");
+MODULE_DESCRIPTION("Freescale QIXIS system controller driver");
+MODULE_LICENSE("GPL");
+
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 10/21] memblock: refactor internal allocation functions
From: Michael Ellerman @ 2019-02-04 8:45 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linux-mm, Andrew Morton, linuxppc-dev, linux-kernel
In-Reply-To: <20190203113915.GC8620@rapoport-lnx>
Mike Rapoport <rppt@linux.ibm.com> writes:
> On Sun, Feb 03, 2019 at 08:39:20PM +1100, Michael Ellerman wrote:
>> Mike Rapoport <rppt@linux.ibm.com> writes:
>> > Currently, memblock has several internal functions with overlapping
>> > functionality. They all call memblock_find_in_range_node() to find free
>> > memory and then reserve the allocated range and mark it with kmemleak.
>> > However, there is difference in the allocation constraints and in fallback
>> > strategies.
...
>>
>> This is causing problems on some of my machines.
...
>>
>> On some of my other systems it does that, and then panics because it
>> can't allocate anything at all:
>>
>> [ 0.000000] numa: NODE_DATA [mem 0x7ffcaee80-0x7ffcb3fff]
>> [ 0.000000] numa: NODE_DATA [mem 0x7ffc99d00-0x7ffc9ee7f]
>> [ 0.000000] numa: NODE_DATA(1) on node 0
>> [ 0.000000] Kernel panic - not syncing: Cannot allocate 20864 bytes for node 16 data
>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc4-gccN-next-20190201-gdc4c899 #1
>> [ 0.000000] Call Trace:
>> [ 0.000000] [c0000000011cfca0] [c000000000c11044] dump_stack+0xe8/0x164 (unreliable)
>> [ 0.000000] [c0000000011cfcf0] [c0000000000fdd6c] panic+0x17c/0x3e0
>> [ 0.000000] [c0000000011cfd90] [c000000000f61bc8] initmem_init+0x128/0x260
>> [ 0.000000] [c0000000011cfe60] [c000000000f57940] setup_arch+0x398/0x418
>> [ 0.000000] [c0000000011cfee0] [c000000000f50a94] start_kernel+0xa0/0x684
>> [ 0.000000] [c0000000011cff90] [c00000000000af70] start_here_common+0x1c/0x52c
>> [ 0.000000] Rebooting in 180 seconds..
>>
>>
>> So there's something going wrong there, I haven't had time to dig into
>> it though (Sunday night here).
>
> Yeah, I've misplaced 'nid' and 'MEMBLOCK_ALLOC_ACCESSIBLE' in
> memblock_phys_alloc_try_nid() :(
>
> Can you please check if the below patch fixes the issue on your systems?
Yes it does, thanks.
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
> From 5875b7440e985ce551e6da3cb28aa8e9af697e10 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport <rppt@linux.ibm.com>
> Date: Sun, 3 Feb 2019 13:35:42 +0200
> Subject: [PATCH] memblock: fix parameter order in
> memblock_phys_alloc_try_nid()
>
> The refactoring of internal memblock allocation functions used wrong order
> of parameters in memblock_alloc_range_nid() call from
> memblock_phys_alloc_try_nid().
> Fix it.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> mm/memblock.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index e047933..0151a5b 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1402,8 +1402,8 @@ phys_addr_t __init memblock_phys_alloc_range(phys_addr_t size,
>
> phys_addr_t __init memblock_phys_alloc_try_nid(phys_addr_t size, phys_addr_t align, int nid)
> {
> - return memblock_alloc_range_nid(size, align, 0, nid,
> - MEMBLOCK_ALLOC_ACCESSIBLE);
> + return memblock_alloc_range_nid(size, align, 0,
> + MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> }
>
> /**
> --
> 2.7.4
>
>
> --
> Sincerely yours,
> Mike.
^ permalink raw reply
* Re: [RFC PATCH] powerpc: fix get_arch_dma_ops() for NTB devices
From: Christoph Hellwig @ 2019-02-04 8:17 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Christoph Hellwig, Alexander Fomichev, linux
In-Reply-To: <87imy6pain.fsf@concordia.ellerman.id.au>
On Wed, Jan 30, 2019 at 11:58:40PM +1100, Michael Ellerman wrote:
> Alexander Fomichev <fomichev.ru@gmail.com> writes:
>
> > get_dma_ops() falls into arch-dependant get_arch_dma_ops(), which
> > historically returns NULL on PowerPC. Therefore dma_set_mask() fails.
> > This affects Switchtec (and probably other) NTB devices, that they fail
> > to initialize.
>
> What's an NTB device?
>
> drivers/ntb I assume?
>
> So it's a PCI device of some sort, but presumably the device you're
> calling dma_set_mask() on is an NTB device not a PCI device?
>
> But then it works if you tell it to use the PCI DMA ops?
>
> At the very least the code should be checking for the NTB bus type and
> only returning the PCI ops in that specific case, not for all devices.
Can you provide the context? E.g. the patch and the rest of the commit
log. This all looks rather odd to me.
^ permalink raw reply
* Re: use generic DMA mapping code in powerpc V4
From: Christoph Hellwig @ 2019-02-04 7:56 UTC (permalink / raw)
To: Christian Zigotzky
Cc: linux-arch, Darren Stevens, linux-kernel, Julian Margetson,
linux-mm, iommu, Paul Mackerras, Olof Johansson, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <594beaae-9681-03de-9f42-191cc7d2f8e3@xenosoft.de>
On Sun, Feb 03, 2019 at 05:49:02PM +0100, Christian Zigotzky wrote:
> OK, next step: b50f42f0fe12965ead395c76bcb6a14f00cdf65b (powerpc/dma: use
> the dma_direct mapping routines)
>
> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
>
> git checkout b50f42f0fe12965ead395c76bcb6a14f00cdf65b
>
> Results: The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet
> doesn't work.
Are there any interesting messages in the boot log? Can you send me
the dmesg?
^ permalink raw reply
* Re: [PATCH] dmaengine: fsldma: Add 64-bit I/O accessors for powerpc64
From: Vinod Koul @ 2019-02-04 7:27 UTC (permalink / raw)
To: Peng Ma
Cc: Wen He, Leo Li, Scott Wood, Zhang Wei, dmaengine@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VI1PR04MB44311D9A8F8CD3A0143BCC99ED9B0@VI1PR04MB4431.eurprd04.prod.outlook.com>
On 25-01-19, 05:54, Peng Ma wrote:
> Hi Vinod,
>
> Sorry to replay late.
> 1:This patch has already send to the patchwork.
> Please see the patch link: https://patchwork.kernel.org/patch/10741521/
> 2:I have already compile the fsl patches on arm and powerpc after patched https://patchwork.kernel.org/patch/10741521/
> The compile will successful, please let me know the reported regression results, thanks very much.
And I thought there were further comments on this patch. I have applied
this, please watch for failures reported if any..
--
~Vinod
^ permalink raw reply
* Re: [PATCH 00/19] KVM: PPC: Book3S HV: add XIVE native exploitation mode
From: David Gibson @ 2019-02-04 5:36 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, linuxppc-dev
In-Reply-To: <06b7c4d2-72ba-ca4f-aded-789280798136@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]
On Sat, Jan 26, 2019 at 09:25:04AM +0100, Cédric Le Goater wrote:
> Was there a crashing.org shutdown ?
>
> Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
> by in5.mail.ovh.net (Postfix) with ESMTPS id 43mYnj0nrlz1N7KC
> for <clg@kaod.org>; Fri, 25 Jan 2019 22:38:00 +0000 (UTC)
> Received: from localhost (localhost.localdomain [127.0.0.1])
> by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x0NLZf4K021092;
> Wed, 23 Jan 2019 15:35:43 -0600
>
>
> On 1/23/19 10:35 PM, Benjamin Herrenschmidt wrote:
> > On Wed, 2019-01-23 at 20:07 +0100, Cédric Le Goater wrote:
> >> Event Assignment Structure, a.k.a IVE (Interrupt Virtualization Entry)
> >>
> >> All the names changed somewhere between XIVE v1 and XIVE v2. OPAL and
> >> Linux should be adjusted ...
> >
> > All the names changed between the HW design and the "architecture"
> > document. The HW guys use the old names, the architecture the new
> > names, and Linux & OPAL mostly use the old ones because frankly the new
> > names suck big time.
>
> Well, It does not make XIVE any clearer ... I did prefer the v1 names
> but there was some naming overlap in the concepts.
>
> >> It would be good to talk a little about the nested support (offline
> >> may be) to make sure that we are not missing some major interface that
> >> would require a lot of change. If we need to prepare ground, I think
> >> the timing is good.
> >>
> >> The size of the IRQ number space might be a problem. It seems we
> >> would need to increase it considerably to support multiple nested
> >> guests. That said I haven't look much how nested is designed.
> >
> > The size of the VP space is a bigger concern. Even today. We really
> > need qemu to tell the max #cpu to KVM so we can allocate less of them.
>
> ah yes. we would also need to reduce the number of available priorities
> per CPU to have more EQ descriptors available if I recall well.
>
> > As for nesting, I suggest for the foreseeable future we stick to XICS
> > emulation in nested guests.
>
> ok. so no kernel_irqchip at all. hmm.
That would certainly be step 0, making sure the capability advertises
this correctly. I think we do want to make XICs-on-XIVE emulation
work in a KVM L1 (so we'd need to have it make XIVE hcalls to the L0
instead of OPAL calls).
XIVE-on-XIVE for L1 would be nice too, which would mean implementing
the XIVE hcalls from the L2 in terms of XIVE hcalls to the L0. I
think it's ok to delay this indefinitely as long as the caps advertise
correctly so that qemu will use userspace emulation until its ready.
> I was wondering how possible it was to have L2 initialize the underlying
> OPAL structures in the L0 hypervisor. May be with a sort of proxy hcall
> which would perform the initialization in QEMU L1 on behalf of L2.
>
--
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 17/19] KVM: PPC: Book3S HV: add get/set accessors for the VP XIVE state
From: David Gibson @ 2019-02-04 5:26 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190107191006.10648-1-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 7408 bytes --]
On Mon, Jan 07, 2019 at 08:10:04PM +0100, Cédric Le Goater wrote:
> 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 structure and merges it in the KVM state.
>
> The structures of the interface between QEMU and KVM provisions some
> extra room (two u64) for further extensions if more state needs to be
> transferred back to QEMU.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/include/asm/kvm_ppc.h | 5 ++
> arch/powerpc/include/uapi/asm/kvm.h | 2 +
> arch/powerpc/kvm/book3s.c | 24 +++++++++
> arch/powerpc/kvm/book3s_xive_native.c | 78 +++++++++++++++++++++++++++
> 4 files changed, 109 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index 4cc897039485..49c488af168c 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -270,6 +270,7 @@ union kvmppc_one_reg {
> u64 addr;
> u64 length;
> } vpaval;
> + u64 xive_timaval[4];
> };
>
> struct kvmppc_ops {
> @@ -603,6 +604,8 @@ 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);
> extern int kvmppc_xive_native_hcall(struct kvm_vcpu *vcpu, u32 cmd);
> +extern int kvmppc_xive_native_get_vp(struct kvm_vcpu *vcpu, union kvmppc_one_reg *val);
> +extern int kvmppc_xive_native_set_vp(struct kvm_vcpu *vcpu, union kvmppc_one_reg *val);
>
> #else
> static inline int kvmppc_xive_set_xive(struct kvm *kvm, u32 irq, u32 server,
> @@ -637,6 +640,8 @@ static inline void kvmppc_xive_native_init_module(void) { }
> static inline void kvmppc_xive_native_exit_module(void) { }
> static inline int kvmppc_xive_native_hcall(struct kvm_vcpu *vcpu, u32 cmd)
> { return 0; }
> +static inline int kvmppc_xive_native_get_vp(struct kvm_vcpu *vcpu, union kvmppc_one_reg *val) { return 0; }
> +static inline int kvmppc_xive_native_set_vp(struct kvm_vcpu *vcpu, union kvmppc_one_reg *val) { return -ENOENT; }
IIRC "VP" is the old name for "TCTX". Since we're using tctx in the
rest of the XIVE code, can we use it here as well.
> #endif /* CONFIG_KVM_XIVE */
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index 95302558ce10..3c958c39a782 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -480,6 +480,8 @@ struct kvm_ppc_cpu_char {
> #define KVM_REG_PPC_ICP_PPRI_SHIFT 16 /* pending irq priority */
> #define KVM_REG_PPC_ICP_PPRI_MASK 0xff
>
> +#define KVM_REG_PPC_VP_STATE (KVM_REG_PPC | KVM_REG_SIZE_U256 | 0x8d)
> +
> /* Device control API: PPC-specific devices */
> #define KVM_DEV_MPIC_GRP_MISC 1
> #define KVM_DEV_MPIC_BASE_ADDR 0 /* 64-bit */
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index de7eed191107..5ad658077a35 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -641,6 +641,18 @@ int kvmppc_get_one_reg(struct kvm_vcpu *vcpu, u64 id,
> *val = get_reg_val(id, kvmppc_xics_get_icp(vcpu));
> break;
> #endif /* CONFIG_KVM_XICS */
> +#ifdef CONFIG_KVM_XIVE
> + case KVM_REG_PPC_VP_STATE:
> + if (!vcpu->arch.xive_vcpu) {
> + r = -ENXIO;
> + break;
> + }
> + if (xive_enabled())
> + r = kvmppc_xive_native_get_vp(vcpu, val);
> + else
> + r = -ENXIO;
> + break;
> +#endif /* CONFIG_KVM_XIVE */
> case KVM_REG_PPC_FSCR:
> *val = get_reg_val(id, vcpu->arch.fscr);
> break;
> @@ -714,6 +726,18 @@ int kvmppc_set_one_reg(struct kvm_vcpu *vcpu, u64 id,
> r = kvmppc_xics_set_icp(vcpu, set_reg_val(id, *val));
> break;
> #endif /* CONFIG_KVM_XICS */
> +#ifdef CONFIG_KVM_XIVE
> + case KVM_REG_PPC_VP_STATE:
> + if (!vcpu->arch.xive_vcpu) {
> + r = -ENXIO;
> + break;
> + }
> + if (xive_enabled())
> + r = kvmppc_xive_native_set_vp(vcpu, val);
> + else
> + r = -ENXIO;
> + break;
> +#endif /* CONFIG_KVM_XIVE */
> case KVM_REG_PPC_FSCR:
> vcpu->arch.fscr = set_reg_val(id, *val);
> break;
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index f4eb71eafc57..1aefb366df0b 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -424,6 +424,84 @@ static int xive_native_validate_queue_size(u32 qsize)
> }
> }
>
> +#define TM_IPB_SHIFT 40
> +#define TM_IPB_MASK (((u64) 0xFF) << TM_IPB_SHIFT)
> +
> +int kvmppc_xive_native_get_vp(struct kvm_vcpu *vcpu, union kvmppc_one_reg *val)
> +{
> + struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> + u64 opal_state;
> + int rc;
> +
> + if (!kvmppc_xive_enabled(vcpu))
> + return -EPERM;
> +
> + if (!xc)
> + return -ENOENT;
> +
> + /* Thread context registers. We only care about IPB and CPPR */
> + val->xive_timaval[0] = vcpu->arch.xive_saved_state.w01;
> +
> + /*
> + * Return the OS CAM line to print out the VP identifier in
> + * the QEMU monitor. This is not restored.
> + */
> + val->xive_timaval[1] = vcpu->arch.xive_cam_word;
> +
> + /* Get the VP state from OPAL */
> + rc = xive_native_get_vp_state(xc->vp_id, &opal_state);
> + if (rc)
> + return rc;
> +
> + /*
> + * Capture the backup of IPB register in the NVT structure and
> + * merge it in our KVM VP state.
> + *
> + * TODO: P10 support.
> + */
> + val->xive_timaval[0] |= cpu_to_be64(opal_state & TM_IPB_MASK);
> +
> + pr_devel("%s NSR=%02x CPPR=%02x IBP=%02x PIPR=%02x w01=%016llx w2=%08x opal=%016llx\n",
> + __func__,
> + 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, opal_state);
> +
> + return 0;
> +}
> +
> +int kvmppc_xive_native_set_vp(struct kvm_vcpu *vcpu, union kvmppc_one_reg *val)
> +{
> + struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> + struct kvmppc_xive *xive = vcpu->kvm->arch.xive;
> +
> + pr_devel("%s w01=%016llx vp=%016llx\n", __func__,
> + val->xive_timaval[0], val->xive_timaval[1]);
> +
> + if (!kvmppc_xive_enabled(vcpu))
> + return -EPERM;
> +
> + if (!xc || !xive)
> + return -ENOENT;
> +
> + /* We can't update the state of a "pushed" VCPU */
> + if (WARN_ON(vcpu->arch.xive_pushed))
> + return -EIO;
> +
> + /* Thread context registers. only restore IPB and CPPR ? */
> + vcpu->arch.xive_saved_state.w01 = val->xive_timaval[0];
> +
> + /*
> + * There is no need to restore the XIVE internal state (IPB
> + * stored in the NVT) as the IPB register was merged in KVM VP
> + * state.
> + */
> + return 0;
> +}
> +
> static int kvmppc_xive_native_set_source(struct kvmppc_xive *xive, long irq,
> u64 addr)
> {
--
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 14/19] KVM: PPC: Book3S HV: add a control to make the XIVE EQ pages dirty
From: David Gibson @ 2019-02-04 5:18 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190107184331.8429-15-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]
On Mon, Jan 07, 2019 at 07:43:26PM +0100, Cédric Le Goater wrote:
> 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 collecting the state of the devices.
Is there a reason to make this a separate step from the SYNC
operation?
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/include/uapi/asm/kvm.h | 1 +
> arch/powerpc/kvm/book3s_xive_native.c | 40 +++++++++++++++++++++++++++
> 2 files changed, 41 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index f3b859223b80..1a8740629acf 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -680,6 +680,7 @@ struct kvm_ppc_cpu_char {
> #define KVM_DEV_XIVE_GET_ESB_FD 1
> #define KVM_DEV_XIVE_GET_TIMA_FD 2
> #define KVM_DEV_XIVE_VC_BASE 3
> +#define KVM_DEV_XIVE_SAVE_EQ_PAGES 4
> #define KVM_DEV_XIVE_GRP_SOURCES 2 /* 64-bit source attributes */
> #define KVM_DEV_XIVE_GRP_SYNC 3 /* 64-bit source attributes */
>
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index a8052867afc1..f2de1bcf3b35 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -373,6 +373,43 @@ static int kvmppc_xive_native_get_tima_fd(struct kvmppc_xive *xive, u64 addr)
> return put_user(ret, ubufp);
> }
>
> +static int kvmppc_xive_native_vcpu_save_eq_pages(struct kvm_vcpu *vcpu)
> +{
> + struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> + unsigned int prio;
> +
> + if (!xc)
> + return -ENOENT;
> +
> + for (prio = 0; prio < KVMPPC_XIVE_Q_COUNT; prio++) {
> + struct xive_q *q = &xc->queues[prio];
> +
> + if (!q->qpage)
> + continue;
> +
> + /* Mark EQ page dirty for migration */
> + mark_page_dirty(vcpu->kvm, gpa_to_gfn(q->guest_qpage));
> + }
> + return 0;
> +}
> +
> +static int kvmppc_xive_native_save_eq_pages(struct kvmppc_xive *xive)
> +{
> + struct kvm *kvm = xive->kvm;
> + struct kvm_vcpu *vcpu;
> + unsigned int i;
> +
> + pr_devel("%s\n", __func__);
> +
> + mutex_lock(&kvm->lock);
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + kvmppc_xive_native_vcpu_save_eq_pages(vcpu);
> + }
> + mutex_unlock(&kvm->lock);
> +
> + return 0;
> +}
> +
> static int xive_native_validate_queue_size(u32 qsize)
> {
> switch (qsize) {
> @@ -498,6 +535,8 @@ static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> switch (attr->attr) {
> case KVM_DEV_XIVE_VC_BASE:
> return kvmppc_xive_native_set_vc_base(xive, attr->addr);
> + case KVM_DEV_XIVE_SAVE_EQ_PAGES:
> + return kvmppc_xive_native_save_eq_pages(xive);
> }
> break;
> case KVM_DEV_XIVE_GRP_SOURCES:
> @@ -538,6 +577,7 @@ static int kvmppc_xive_native_has_attr(struct kvm_device *dev,
> case KVM_DEV_XIVE_GET_ESB_FD:
> case KVM_DEV_XIVE_GET_TIMA_FD:
> case KVM_DEV_XIVE_VC_BASE:
> + case KVM_DEV_XIVE_SAVE_EQ_PAGES:
> return 0;
> }
> break;
--
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 13/19] KVM: PPC: Book3S HV: add a SYNC control for the XIVE native migration
From: David Gibson @ 2019-02-04 5:17 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190107184331.8429-14-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 3368 bytes --]
On Mon, Jan 07, 2019 at 07:43:25PM +0100, Cédric Le Goater wrote:
> 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 the KVM ioctl KVM_DEV_XIVE_GRP_SYNC.
>
Don't you also need to make sure the guests queue pages are marked
dirty here, in case they were already migrated?
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/include/uapi/asm/kvm.h | 1 +
> arch/powerpc/kvm/book3s_xive_native.c | 32 +++++++++++++++++++++++++++
> 2 files changed, 33 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index 6fc9660c5aec..f3b859223b80 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -681,6 +681,7 @@ struct kvm_ppc_cpu_char {
> #define KVM_DEV_XIVE_GET_TIMA_FD 2
> #define KVM_DEV_XIVE_VC_BASE 3
> #define KVM_DEV_XIVE_GRP_SOURCES 2 /* 64-bit source attributes */
> +#define KVM_DEV_XIVE_GRP_SYNC 3 /* 64-bit source attributes */
>
> /* Layout of 64-bit XIVE source attribute values */
> #define KVM_XIVE_LEVEL_SENSITIVE (1ULL << 0)
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index 4ca75aade069..a8052867afc1 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -459,6 +459,35 @@ static int kvmppc_xive_native_set_source(struct kvmppc_xive *xive, long irq,
> return 0;
> }
>
> +static int kvmppc_xive_native_sync(struct kvmppc_xive *xive, long irq, u64 addr)
> +{
> + struct kvmppc_xive_src_block *sb;
> + struct kvmppc_xive_irq_state *state;
> + struct xive_irq_data *xd;
> + u32 hw_num;
> + u16 src;
> +
> + pr_devel("%s irq=0x%lx\n", __func__, irq);
> +
> + sb = kvmppc_xive_find_source(xive, irq, &src);
> + if (!sb)
> + return -ENOENT;
> +
> + state = &sb->irq_state[src];
> +
> + if (!state->valid)
> + return -ENOENT;
> +
> + arch_spin_lock(&sb->lock);
> +
> + kvmppc_xive_select_irq(state, &hw_num, &xd);
> + xive_native_sync_source(hw_num);
> + xive_native_sync_queue(hw_num);
> +
> + arch_spin_unlock(&sb->lock);
> + return 0;
> +}
> +
> static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> @@ -474,6 +503,8 @@ static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> case KVM_DEV_XIVE_GRP_SOURCES:
> return kvmppc_xive_native_set_source(xive, attr->attr,
> attr->addr);
> + case KVM_DEV_XIVE_GRP_SYNC:
> + return kvmppc_xive_native_sync(xive, attr->attr, attr->addr);
> }
> return -ENXIO;
> }
> @@ -511,6 +542,7 @@ static int kvmppc_xive_native_has_attr(struct kvm_device *dev,
> }
> break;
> case KVM_DEV_XIVE_GRP_SOURCES:
> + case KVM_DEV_XIVE_GRP_SYNC:
> if (attr->attr >= KVMPPC_XIVE_FIRST_IRQ &&
> attr->attr < KVMPPC_XIVE_NR_IRQS)
> return 0;
--
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 16/19] KVM: PPC: Book3S HV: add get/set accessors for the EQ configuration
From: David Gibson @ 2019-02-04 5:24 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190107184331.8429-17-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 8455 bytes --]
On Mon, Jan 07, 2019 at 07:43:28PM +0100, Cédric Le Goater wrote:
> 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 <clg@kaod.org>
> ---
> arch/powerpc/include/uapi/asm/kvm.h | 21 ++++
> arch/powerpc/kvm/book3s_xive_native.c | 166 ++++++++++++++++++++++++++
> 2 files changed, 187 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index faf024f39858..95302558ce10 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -684,6 +684,7 @@ struct kvm_ppc_cpu_char {
> #define KVM_DEV_XIVE_GRP_SOURCES 2 /* 64-bit source attributes */
> #define KVM_DEV_XIVE_GRP_SYNC 3 /* 64-bit source attributes */
> #define KVM_DEV_XIVE_GRP_EAS 4 /* 64-bit eas attributes */
> +#define KVM_DEV_XIVE_GRP_EQ 5 /* 64-bit eq attributes */
>
> /* Layout of 64-bit XIVE source attribute values */
> #define KVM_XIVE_LEVEL_SENSITIVE (1ULL << 0)
> @@ -699,4 +700,24 @@ struct kvm_ppc_cpu_char {
> #define KVM_XIVE_EAS_EISN_SHIFT 33
> #define KVM_XIVE_EAS_EISN_MASK 0xfffffffe00000000ULL
>
> +/* Layout of 64-bit eq attribute */
> +#define KVM_XIVE_EQ_PRIORITY_SHIFT 0
> +#define KVM_XIVE_EQ_PRIORITY_MASK 0x7
> +#define KVM_XIVE_EQ_SERVER_SHIFT 3
> +#define KVM_XIVE_EQ_SERVER_MASK 0xfffffff8ULL
> +
> +/* Layout of 64-bit eq attribute values */
> +struct kvm_ppc_xive_eq {
> + __u32 flags;
> + __u32 qsize;
> + __u64 qpage;
> + __u32 qtoggle;
> + __u32 qindex;
Should we pad this in case a) we discover some fields in the EQ that
we thought weren't relevant to the guest actually are or b) future
XIVE extensions add something we need to migrate.
> +};
> +
> +#define KVM_XIVE_EQ_FLAG_ENABLED 0x00000001
> +#define KVM_XIVE_EQ_FLAG_ALWAYS_NOTIFY 0x00000002
> +#define KVM_XIVE_EQ_FLAG_ESCALATE 0x00000004
> +
> +
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index 0468b605baa7..f4eb71eafc57 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -607,6 +607,164 @@ static int kvmppc_xive_native_get_eas(struct kvmppc_xive *xive, long irq,
> return 0;
> }
>
> +static int kvmppc_xive_native_set_queue(struct kvmppc_xive *xive, long eq_idx,
> + u64 addr)
> +{
> + struct kvm *kvm = xive->kvm;
> + struct kvm_vcpu *vcpu;
> + struct kvmppc_xive_vcpu *xc;
> + void __user *ubufp = (u64 __user *) addr;
> + u32 server;
> + u8 priority;
> + struct kvm_ppc_xive_eq kvm_eq;
> + int rc;
> + __be32 *qaddr = 0;
> + struct page *page;
> + struct xive_q *q;
> +
> + /*
> + * Demangle priority/server tuple from the EQ index
> + */
> + priority = (eq_idx & KVM_XIVE_EQ_PRIORITY_MASK) >>
> + KVM_XIVE_EQ_PRIORITY_SHIFT;
> + server = (eq_idx & KVM_XIVE_EQ_SERVER_MASK) >>
> + KVM_XIVE_EQ_SERVER_SHIFT;
> +
> + if (copy_from_user(&kvm_eq, ubufp, sizeof(kvm_eq)))
> + return -EFAULT;
> +
> + vcpu = kvmppc_xive_find_server(kvm, server);
> + if (!vcpu) {
> + pr_err("Can't find server %d\n", server);
> + return -ENOENT;
> + }
> + xc = vcpu->arch.xive_vcpu;
> +
> + if (priority != xive_prio_from_guest(priority)) {
> + pr_err("Trying to restore invalid queue %d for VCPU %d\n",
> + priority, server);
> + return -EINVAL;
> + }
> + q = &xc->queues[priority];
> +
> + pr_devel("%s VCPU %d priority %d fl:%x sz:%d addr:%llx g:%d idx:%d\n",
> + __func__, server, priority, kvm_eq.flags,
> + kvm_eq.qsize, kvm_eq.qpage, kvm_eq.qtoggle, kvm_eq.qindex);
> +
> + rc = xive_native_validate_queue_size(kvm_eq.qsize);
> + if (rc || !kvm_eq.qsize) {
> + pr_err("invalid queue size %d\n", kvm_eq.qsize);
> + return rc;
> + }
> +
> + page = gfn_to_page(kvm, gpa_to_gfn(kvm_eq.qpage));
> + if (is_error_page(page)) {
> + pr_warn("Couldn't get guest page for %llx!\n", kvm_eq.qpage);
> + return -ENOMEM;
> + }
> + qaddr = page_to_virt(page) + (kvm_eq.qpage & ~PAGE_MASK);
> +
> + /* Backup queue page guest address for migration */
> + q->guest_qpage = kvm_eq.qpage;
> + q->guest_qsize = kvm_eq.qsize;
> +
> + rc = xive_native_configure_queue(xc->vp_id, q, priority,
> + (__be32 *) qaddr, kvm_eq.qsize, true);
> + if (rc) {
> + pr_err("Failed to configure queue %d for VCPU %d: %d\n",
> + priority, xc->server_num, rc);
> + put_page(page);
> + return rc;
> + }
> +
> + rc = xive_native_set_queue_state(xc->vp_id, priority, kvm_eq.qtoggle,
> + kvm_eq.qindex);
> + if (rc)
> + goto error;
> +
> + rc = kvmppc_xive_attach_escalation(vcpu, priority);
> +error:
> + if (rc)
> + xive_native_cleanup_queue(vcpu, priority);
> + return rc;
> +}
> +
> +static int kvmppc_xive_native_get_queue(struct kvmppc_xive *xive, long eq_idx,
> + u64 addr)
> +{
> + struct kvm *kvm = xive->kvm;
> + struct kvm_vcpu *vcpu;
> + struct kvmppc_xive_vcpu *xc;
> + struct xive_q *q;
> + void __user *ubufp = (u64 __user *) addr;
> + u32 server;
> + u8 priority;
> + struct kvm_ppc_xive_eq kvm_eq;
> + u64 qpage;
> + u64 qsize;
> + u64 qeoi_page;
> + u32 escalate_irq;
> + u64 qflags;
> + int rc;
> +
> + /*
> + * Demangle priority/server tuple from the EQ index
> + */
> + priority = (eq_idx & KVM_XIVE_EQ_PRIORITY_MASK) >>
> + KVM_XIVE_EQ_PRIORITY_SHIFT;
> + server = (eq_idx & KVM_XIVE_EQ_SERVER_MASK) >>
> + KVM_XIVE_EQ_SERVER_SHIFT;
> +
> + vcpu = kvmppc_xive_find_server(kvm, server);
> + if (!vcpu) {
> + pr_err("Can't find server %d\n", server);
> + return -ENOENT;
> + }
> + xc = vcpu->arch.xive_vcpu;
> +
> + if (priority != xive_prio_from_guest(priority)) {
> + pr_err("invalid priority for queue %d for VCPU %d\n",
> + priority, server);
> + return -EINVAL;
> + }
> + q = &xc->queues[priority];
> +
> + memset(&kvm_eq, 0, sizeof(kvm_eq));
> +
> + if (!q->qpage)
> + return 0;
> +
> + rc = xive_native_get_queue_info(xc->vp_id, priority, &qpage, &qsize,
> + &qeoi_page, &escalate_irq, &qflags);
> + if (rc)
> + return rc;
> +
> + kvm_eq.flags = 0;
> + if (qflags & OPAL_XIVE_EQ_ENABLED)
> + kvm_eq.flags |= KVM_XIVE_EQ_FLAG_ENABLED;
> + if (qflags & OPAL_XIVE_EQ_ALWAYS_NOTIFY)
> + kvm_eq.flags |= KVM_XIVE_EQ_FLAG_ALWAYS_NOTIFY;
> + if (qflags & OPAL_XIVE_EQ_ESCALATE)
> + kvm_eq.flags |= KVM_XIVE_EQ_FLAG_ESCALATE;
> +
> + kvm_eq.qsize = q->guest_qsize;
> + kvm_eq.qpage = q->guest_qpage;
> +
> + rc = xive_native_get_queue_state(xc->vp_id, priority, &kvm_eq.qtoggle,
> + &kvm_eq.qindex);
> + if (rc)
> + return rc;
> +
> + pr_devel("%s VCPU %d priority %d fl:%x sz:%d addr:%llx g:%d idx:%d\n",
> + __func__, server, priority, kvm_eq.flags,
> + kvm_eq.qsize, kvm_eq.qpage, kvm_eq.qtoggle, kvm_eq.qindex);
> +
> + if (copy_to_user(ubufp, &kvm_eq, sizeof(kvm_eq)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> @@ -628,6 +786,9 @@ static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> return kvmppc_xive_native_sync(xive, attr->attr, attr->addr);
> case KVM_DEV_XIVE_GRP_EAS:
> return kvmppc_xive_native_set_eas(xive, attr->attr, attr->addr);
> + case KVM_DEV_XIVE_GRP_EQ:
> + return kvmppc_xive_native_set_queue(xive, attr->attr,
> + attr->addr);
> }
> return -ENXIO;
> }
> @@ -650,6 +811,9 @@ static int kvmppc_xive_native_get_attr(struct kvm_device *dev,
> break;
> case KVM_DEV_XIVE_GRP_EAS:
> return kvmppc_xive_native_get_eas(xive, attr->attr, attr->addr);
> + case KVM_DEV_XIVE_GRP_EQ:
> + return kvmppc_xive_native_get_queue(xive, attr->attr,
> + attr->addr);
> }
> return -ENXIO;
> }
> @@ -674,6 +838,8 @@ static int kvmppc_xive_native_has_attr(struct kvm_device *dev,
> attr->attr < KVMPPC_XIVE_NR_IRQS)
> return 0;
> break;
> + case KVM_DEV_XIVE_GRP_EQ:
> + return 0;
> }
> return -ENXIO;
> }
--
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 15/19] KVM: PPC: Book3S HV: add get/set accessors for the source configuration
From: David Gibson @ 2019-02-04 5:21 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190107184331.8429-16-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 5861 bytes --]
On Mon, Jan 07, 2019 at 07:43:27PM +0100, Cédric Le Goater wrote:
> 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 <clg@kaod.org>
> ---
> arch/powerpc/include/uapi/asm/kvm.h | 11 ++++
> arch/powerpc/kvm/book3s_xive_native.c | 87 +++++++++++++++++++++++++++
> 2 files changed, 98 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index 1a8740629acf..faf024f39858 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -683,9 +683,20 @@ struct kvm_ppc_cpu_char {
> #define KVM_DEV_XIVE_SAVE_EQ_PAGES 4
> #define KVM_DEV_XIVE_GRP_SOURCES 2 /* 64-bit source attributes */
> #define KVM_DEV_XIVE_GRP_SYNC 3 /* 64-bit source attributes */
> +#define KVM_DEV_XIVE_GRP_EAS 4 /* 64-bit eas 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 eas attribute values */
> +#define KVM_XIVE_EAS_PRIORITY_SHIFT 0
> +#define KVM_XIVE_EAS_PRIORITY_MASK 0x7
> +#define KVM_XIVE_EAS_SERVER_SHIFT 3
> +#define KVM_XIVE_EAS_SERVER_MASK 0xfffffff8ULL
> +#define KVM_XIVE_EAS_MASK_SHIFT 32
> +#define KVM_XIVE_EAS_MASK_MASK 0x100000000ULL
> +#define KVM_XIVE_EAS_EISN_SHIFT 33
> +#define KVM_XIVE_EAS_EISN_MASK 0xfffffffe00000000ULL
> +
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index f2de1bcf3b35..0468b605baa7 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -525,6 +525,88 @@ static int kvmppc_xive_native_sync(struct kvmppc_xive *xive, long irq, u64 addr)
> return 0;
> }
>
> +static int kvmppc_xive_native_set_eas(struct kvmppc_xive *xive, long irq,
> + u64 addr)
I'd prefer to avoid the name "EAS" here. IIUC these aren't "raw" EAS
values, but rather essentially the "source config" in the terminology
of the PAPR hcalls. Which, yes, is basically implemented by setting
the EAS, but since it's the PAPR architected state that we need to
preserve across migration, I'd prefer to stick as close as we can to
the PAPR terminology.
> +{
> + struct kvmppc_xive_src_block *sb;
> + struct kvmppc_xive_irq_state *state;
> + u64 __user *ubufp = (u64 __user *) addr;
> + u16 src;
> + u64 kvm_eas;
> + 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_eas, ubufp))
> + return -EFAULT;
> +
> + pr_devel("%s irq=0x%lx eas=%016llx\n", __func__, irq, kvm_eas);
> +
> + priority = (kvm_eas & KVM_XIVE_EAS_PRIORITY_MASK) >>
> + KVM_XIVE_EAS_PRIORITY_SHIFT;
> + server = (kvm_eas & KVM_XIVE_EAS_SERVER_MASK) >>
> + KVM_XIVE_EAS_SERVER_SHIFT;
> + eisn = (kvm_eas & KVM_XIVE_EAS_EISN_MASK) >> KVM_XIVE_EAS_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_set_source_config(xive, sb, state, server,
> + priority, eisn);
> +}
> +
> +static int kvmppc_xive_native_get_eas(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_eas;
> +
> + sb = kvmppc_xive_find_source(xive, irq, &src);
> + if (!sb)
> + return -ENOENT;
> +
> + state = &sb->irq_state[src];
> +
> + if (!state->valid)
> + return -EINVAL;
> +
> + arch_spin_lock(&sb->lock);
> +
> + if (state->act_priority == MASKED)
> + kvm_eas = KVM_XIVE_EAS_MASK_MASK;
> + else {
> + kvm_eas = (state->act_priority << KVM_XIVE_EAS_PRIORITY_SHIFT) &
> + KVM_XIVE_EAS_PRIORITY_MASK;
> + kvm_eas |= (state->act_server << KVM_XIVE_EAS_SERVER_SHIFT) &
> + KVM_XIVE_EAS_SERVER_MASK;
> + kvm_eas |= ((u64) state->eisn << KVM_XIVE_EAS_EISN_SHIFT) &
> + KVM_XIVE_EAS_EISN_MASK;
> + }
> + arch_spin_unlock(&sb->lock);
> +
> + pr_devel("%s irq=0x%lx eas=%016llx\n", __func__, irq, kvm_eas);
> +
> + if (put_user(kvm_eas, ubufp))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> @@ -544,6 +626,8 @@ static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> attr->addr);
> case KVM_DEV_XIVE_GRP_SYNC:
> return kvmppc_xive_native_sync(xive, attr->attr, attr->addr);
> + case KVM_DEV_XIVE_GRP_EAS:
> + return kvmppc_xive_native_set_eas(xive, attr->attr, attr->addr);
> }
> return -ENXIO;
> }
> @@ -564,6 +648,8 @@ static int kvmppc_xive_native_get_attr(struct kvm_device *dev,
> return kvmppc_xive_native_get_vc_base(xive, attr->addr);
> }
> break;
> + case KVM_DEV_XIVE_GRP_EAS:
> + return kvmppc_xive_native_get_eas(xive, attr->attr, attr->addr);
> }
> return -ENXIO;
> }
> @@ -583,6 +669,7 @@ static int kvmppc_xive_native_has_attr(struct kvm_device *dev,
> break;
> case KVM_DEV_XIVE_GRP_SOURCES:
> case KVM_DEV_XIVE_GRP_SYNC:
> + case KVM_DEV_XIVE_GRP_EAS:
> if (attr->attr >= KVMPPC_XIVE_FIRST_IRQ &&
> attr->attr < KVMPPC_XIVE_NR_IRQS)
> return 0;
--
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 08/19] KVM: PPC: Book3S HV: add a VC_BASE control to the XIVE native device
From: David Gibson @ 2019-02-04 4:49 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, linuxppc-dev
In-Reply-To: <8c45581e-466e-a390-e9cd-a06b5939d2af@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
On Wed, Jan 23, 2019 at 05:56:26PM +0100, Cédric Le Goater wrote:
> On 1/22/19 6:14 AM, Paul Mackerras wrote:
> > On Mon, Jan 07, 2019 at 07:43:20PM +0100, Cédric Le Goater wrote:
> >> 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, add a VC_BASE control to the KVM XIVE device
> >
> > This needs a little more explanation. I *think* the only way this
> > gets used is that it gets returned to the guest by the new
> > hypercalls. If that is indeed the case it would be useful to mention
> > that in the patch description, because otherwise taking a value that
> > userspace provides and which looks like it is an address, and not
> > doing any validation on it, looks a bit scary.
>
> I think we have solved this problem in another email thread.
>
> The H_INT_GET_SOURCE_INFO hcall does not need to be implemented in KVM
> as all the source information should already be available in QEMU. In
> that case, there is no need to inform KVM of where the ESB pages are
> mapped in the guest address space. So we don't need that extra control
> on the KVM device. This is good news.
Ah, good to hear. I thought this looked strange.
--
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 12/19] KVM: PPC: Book3S HV: record guest queue page address
From: David Gibson @ 2019-02-04 5:15 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190107184331.8429-13-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]
On Mon, Jan 07, 2019 at 07:43:24PM +0100, Cédric Le Goater wrote:
> 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.
That doesn't sound like a very compelling case - migration is already
a hundreds of milliseconds type operation, I wouldn't expect a few
extra OPAL calls to be an issue.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/include/asm/xive.h | 2 ++
> arch/powerpc/kvm/book3s_xive_native.c | 4 ++++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/xive.h b/arch/powerpc/include/asm/xive.h
> index 7a7aa22d8258..e90c3c5d9533 100644
> --- a/arch/powerpc/include/asm/xive.h
> +++ b/arch/powerpc/include/asm/xive.h
> @@ -74,6 +74,8 @@ struct xive_q {
> u32 esc_irq;
> atomic_t count;
> atomic_t pending_count;
> + u64 guest_qpage;
> + u32 guest_qsize;
> };
>
> /* Global enable flags for the XIVE support */
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index 35d806740c3a..4ca75aade069 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -708,6 +708,10 @@ static int kvmppc_h_int_set_queue_config(struct kvm_vcpu *vcpu,
> }
> qaddr = page_to_virt(page) + (qpage & ~PAGE_MASK);
>
> + /* Backup queue page address and size for migration */
> + q->guest_qpage = qpage;
> + q->guest_qsize = qsize;
> +
> rc = xive_native_configure_queue(xc->vp_id, q, priority,
> (__be32 *) qaddr, qsize, true);
> if (rc) {
--
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 09/19] KVM: PPC: Book3S HV: add a SET_SOURCE control to the XIVE native device
From: David Gibson @ 2019-02-04 4:57 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190107184331.8429-10-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 6693 bytes --]
On Mon, Jan 07, 2019 at 07:43:21PM +0100, Cédric Le Goater wrote:
> Interrupt sources are simply created at the OPAL level and then
> MASKED. KVM only needs to know about their type: LSI or MSI.
This commit message isn't very illuminating.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/include/uapi/asm/kvm.h | 5 +
> arch/powerpc/kvm/book3s_xive_native.c | 98 +++++++++++++++++++
> .../powerpc/kvm/book3s_xive_native_template.c | 27 +++++
> 3 files changed, 130 insertions(+)
> create mode 100644 arch/powerpc/kvm/book3s_xive_native_template.c
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index 8b78b12aa118..6fc9660c5aec 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -680,5 +680,10 @@ struct kvm_ppc_cpu_char {
> #define KVM_DEV_XIVE_GET_ESB_FD 1
> #define KVM_DEV_XIVE_GET_TIMA_FD 2
> #define KVM_DEV_XIVE_VC_BASE 3
> +#define KVM_DEV_XIVE_GRP_SOURCES 2 /* 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)
>
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index 29a62914de55..2518640d4a58 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -31,6 +31,24 @@
>
> #include "book3s_xive.h"
>
> +/*
> + * We still instantiate them here because we use some of the
> + * generated utility functions as well in this file.
And this comment is downright cryptic.
> + */
> +#define XIVE_RUNTIME_CHECKS
> +#define X_PFX xive_vm_
> +#define X_STATIC static
> +#define X_STAT_PFX stat_vm_
> +#define __x_tima xive_tima
> +#define __x_eoi_page(xd) ((void __iomem *)((xd)->eoi_mmio))
> +#define __x_trig_page(xd) ((void __iomem *)((xd)->trig_mmio))
> +#define __x_writeb __raw_writeb
> +#define __x_readw __raw_readw
> +#define __x_readq __raw_readq
> +#define __x_writeq __raw_writeq
> +
> +#include "book3s_xive_native_template.c"
> +
> static void xive_native_cleanup_queue(struct kvm_vcpu *vcpu, int prio)
> {
> struct kvmppc_xive_vcpu *xc = vcpu->arch.xive_vcpu;
> @@ -305,6 +323,78 @@ static int kvmppc_xive_native_get_tima_fd(struct kvmppc_xive *xive, u64 addr)
> return put_user(ret, ubufp);
> }
>
> +static int kvmppc_xive_native_set_source(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;
> + u64 val;
> + u16 idx;
> +
> + pr_devel("%s irq=0x%lx\n", __func__, irq);
> +
> + if (irq < KVMPPC_XIVE_FIRST_IRQ || irq >= KVMPPC_XIVE_NR_IRQS)
> + return -ENOENT;
> +
> + sb = kvmppc_xive_find_source(xive, irq, &idx);
> + if (!sb) {
> + pr_debug("No source, creating source block...\n");
Doesn't this need to be protected by some lock?
> + sb = kvmppc_xive_create_src_block(xive, irq);
> + if (!sb) {
> + pr_err("Failed to create block...\n");
> + return -ENOMEM;
> + }
> + }
> + state = &sb->irq_state[idx];
> +
> + if (get_user(val, ubufp)) {
> + pr_err("fault getting user info !\n");
> + return -EFAULT;
> + }
> +
> + /*
> + * If the source doesn't already have an IPI, allocate
> + * one and get the corresponding data
> + */
> + if (!state->ipi_number) {
> + state->ipi_number = xive_native_alloc_irq();
> + if (state->ipi_number == 0) {
> + pr_err("Failed to allocate IRQ !\n");
> + return -ENOMEM;
> + }
Am I right in thinking this is the point at which a specific guest irq
number gets bound to a specific host irq number?
> + xive_native_populate_irq_data(state->ipi_number,
> + &state->ipi_data);
> + pr_debug("%s allocated hw_irq=0x%x for irq=0x%lx\n", __func__,
> + state->ipi_number, irq);
> + }
> +
> + arch_spin_lock(&sb->lock);
> +
> + /* Restore LSI state */
> + if (val & KVM_XIVE_LEVEL_SENSITIVE) {
> + state->lsi = true;
> + if (val & KVM_XIVE_LEVEL_ASSERTED)
> + state->asserted = true;
> + pr_devel(" LSI ! Asserted=%d\n", state->asserted);
> + }
> +
> + /* Mask IRQ to start with */
> + state->act_server = 0;
> + state->act_priority = MASKED;
> + xive_vm_esb_load(&state->ipi_data, XIVE_ESB_SET_PQ_01);
> + xive_native_configure_irq(state->ipi_number, 0, MASKED, 0);
> +
> + /* Increment the number of valid sources and mark this one valid */
> + if (!state->valid)
> + xive->src_count++;
> + state->valid = true;
> +
> + arch_spin_unlock(&sb->lock);
> +
> + return 0;
> +}
> +
> static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> @@ -317,6 +407,9 @@ static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> return kvmppc_xive_native_set_vc_base(xive, attr->addr);
> }
> break;
> + case KVM_DEV_XIVE_GRP_SOURCES:
> + return kvmppc_xive_native_set_source(xive, attr->attr,
> + attr->addr);
> }
> return -ENXIO;
> }
> @@ -353,6 +446,11 @@ static int kvmppc_xive_native_has_attr(struct kvm_device *dev,
> return 0;
> }
> break;
> + case KVM_DEV_XIVE_GRP_SOURCES:
> + if (attr->attr >= KVMPPC_XIVE_FIRST_IRQ &&
> + attr->attr < KVMPPC_XIVE_NR_IRQS)
> + return 0;
> + break;
> }
> return -ENXIO;
> }
> diff --git a/arch/powerpc/kvm/book3s_xive_native_template.c b/arch/powerpc/kvm/book3s_xive_native_template.c
> new file mode 100644
> index 000000000000..e7260da4a596
> --- /dev/null
> +++ b/arch/powerpc/kvm/book3s_xive_native_template.c
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2017-2019, IBM Corporation.
> + */
> +
> +/* File to be included by other .c files */
> +
> +#define XGLUE(a, b) a##b
> +#define GLUE(a, b) XGLUE(a, b)
> +
> +/*
> + * TODO: introduce a common template file with the XIVE native layer
> + * and the XICS-on-XIVE glue for the utility functions
> + */
> +static u8 GLUE(X_PFX, esb_load)(struct xive_irq_data *xd, u32 offset)
> +{
> + u64 val;
> +
> + if (xd->flags & XIVE_IRQ_FLAG_SHIFT_BUG)
> + offset |= offset << 4;
> +
> + val = __x_readq(__x_eoi_page(xd) + offset);
> +#ifdef __LITTLE_ENDIAN__
> + val >>= 64-8;
> +#endif
> + return (u8)val;
> +}
--
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 06/19] KVM: PPC: Book3S HV: add a GET_ESB_FD control to the XIVE native device
From: David Gibson @ 2019-02-04 4:45 UTC (permalink / raw)
To: Cédric Le Goater; +Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <20190107184331.8429-7-clg@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 4916 bytes --]
On Mon, Jan 07, 2019 at 07:43:18PM +0100, Cédric Le Goater wrote:
> 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 <clg@kaod.org>
> ---
> arch/powerpc/include/uapi/asm/kvm.h | 4 ++
> arch/powerpc/kvm/book3s_xive_native.c | 97 +++++++++++++++++++++++++++
> 2 files changed, 101 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> index 8c876c166ef2..6bb61ba141c2 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -675,4 +675,8 @@ 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
> +#define KVM_DEV_XIVE_GET_ESB_FD 1
Introducing a new FD for ESB and TIMA seems overkill. Can't you get
to both with an mmap() directly on the xive device fd? Using the
offset to distinguish which one to map, obviously.
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index 115143e76c45..e20081f0c8d4 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -153,6 +153,85 @@ int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev,
> return rc;
> }
>
> +static int xive_native_esb_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct kvmppc_xive *xive = vma->vm_file->private_data;
> + struct kvmppc_xive_src_block *sb;
> + struct kvmppc_xive_irq_state *state;
> + struct xive_irq_data *xd;
> + u32 hw_num;
> + u16 src;
> + u64 page;
> + unsigned long irq;
> +
> + /*
> + * Linux/KVM uses a two pages ESB setting, one for trigger and
> + * one for EOI
> + */
> + irq = vmf->pgoff / 2;
> +
> + sb = kvmppc_xive_find_source(xive, irq, &src);
> + if (!sb) {
> + pr_err("%s: source %lx not found !\n", __func__, irq);
> + return VM_FAULT_SIGBUS;
> + }
> +
> + state = &sb->irq_state[src];
> + kvmppc_xive_select_irq(state, &hw_num, &xd);
> +
> + arch_spin_lock(&sb->lock);
> +
> + /*
> + * first/even page is for trigger
> + * second/odd page is for EOI and management.
> + */
> + page = vmf->pgoff % 2 ? xd->eoi_page : xd->trig_page;
> + arch_spin_unlock(&sb->lock);
> +
> + if (!page) {
> + pr_err("%s: acessing invalid ESB page for source %lx !\n",
> + __func__, irq);
> + return VM_FAULT_SIGBUS;
> + }
> +
> + vmf_insert_pfn(vma, vmf->address, page >> PAGE_SHIFT);
> + return VM_FAULT_NOPAGE;
> +}
> +
> +static const struct vm_operations_struct xive_native_esb_vmops = {
> + .fault = xive_native_esb_fault,
> +};
> +
> +static int xive_native_esb_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + /* There are two ESB pages (trigger and EOI) per IRQ */
> + if (vma_pages(vma) + vma->vm_pgoff > KVMPPC_XIVE_NR_IRQS * 2)
> + return -EINVAL;
> +
> + vma->vm_flags |= VM_IO | VM_PFNMAP;
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> + vma->vm_ops = &xive_native_esb_vmops;
> + return 0;
> +}
> +
> +static const struct file_operations xive_native_esb_fops = {
> + .mmap = xive_native_esb_mmap,
> +};
> +
> +static int kvmppc_xive_native_get_esb_fd(struct kvmppc_xive *xive, u64 addr)
> +{
> + u64 __user *ubufp = (u64 __user *) addr;
> + int ret;
> +
> + ret = anon_inode_getfd("[xive-esb]", &xive_native_esb_fops, xive,
> + O_RDWR | O_CLOEXEC);
> + if (ret < 0)
> + return ret;
> +
> + return put_user(ret, ubufp);
> +}
> +
> static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> @@ -162,12 +241,30 @@ static int kvmppc_xive_native_set_attr(struct kvm_device *dev,
> static int kvmppc_xive_native_get_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> + struct kvmppc_xive *xive = dev->private;
> +
> + switch (attr->group) {
> + case KVM_DEV_XIVE_GRP_CTRL:
> + switch (attr->attr) {
> + case KVM_DEV_XIVE_GET_ESB_FD:
> + return kvmppc_xive_native_get_esb_fd(xive, attr->addr);
> + }
> + break;
> + }
> 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:
> + switch (attr->attr) {
> + case KVM_DEV_XIVE_GET_ESB_FD:
> + return 0;
> + }
> + break;
> + }
> return -ENXIO;
> }
>
--
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
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