From: Christoffer Dall <christoffer.dall@linaro.org> To: Eric Auger <eric.auger@linaro.org> Cc: eric.auger@st.com, marc.zyngier@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, alex.williamson@redhat.com, joel.schopp@amd.com, kim.phillips@freescale.com, paulus@samba.org, gleb@kernel.org, pbonzini@redhat.com, linux-kernel@vger.kernel.org, patches@linaro.org, will.deacon@arm.com, a.motakis@virtualopensystems.com, a.rigo@virtualopensystems.com, john.liuli@huawei.com Subject: Re: [RFC v2 9/9] KVM: KVM-VFIO: ARM forwarding control Date: Thu, 11 Sep 2014 05:10:32 +0200 [thread overview] Message-ID: <20140911031032.GJ2784@lvm> (raw) In-Reply-To: <1409575968-5329-10-git-send-email-eric.auger@linaro.org> On Mon, Sep 01, 2014 at 02:52:48PM +0200, Eric Auger wrote: > Enables forwarding control for ARM. By defining > __KVM_HAVE_ARCH_KVM_VFIO_FORWARD the patch enables > KVM_DEV_VFIO_DEVICE_FORWARD/UNFORWARD_IRQ command on ARM. As a > result it brings an optimized injection/completion handling for > forwarded IRQ. The ARM specific part is implemented in a new module, a new module ?!? you mean file, right? > kvm_vfio_arm.c > > Signed-off-by: Eric Auger <eric.auger@linaro.org> > --- > arch/arm/include/asm/kvm_host.h | 2 + > arch/arm/kvm/Makefile | 2 +- > arch/arm/kvm/kvm_vfio_arm.c | 85 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 88 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/kvm/kvm_vfio_arm.c > > diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h > index 1aee6bb..dfd3b05 100644 > --- a/arch/arm/include/asm/kvm_host.h > +++ b/arch/arm/include/asm/kvm_host.h > @@ -25,6 +25,8 @@ > #include <asm/fpstate.h> > #include <kvm/arm_arch_timer.h> > > +#define __KVM_HAVE_ARCH_KVM_VFIO_FORWARD > + > #if defined(CONFIG_KVM_ARM_MAX_VCPUS) > #define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS > #else > diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile > index ea1fa76..26a5a42 100644 > --- a/arch/arm/kvm/Makefile > +++ b/arch/arm/kvm/Makefile > @@ -19,7 +19,7 @@ kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o $(KVM)/vf > > obj-y += kvm-arm.o init.o interrupts.o > obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o > -obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o > +obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o kvm_vfio_arm.o > obj-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic.o > obj-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic-v2.o > obj-$(CONFIG_KVM_ARM_TIMER) += $(KVM)/arm/arch_timer.o > diff --git a/arch/arm/kvm/kvm_vfio_arm.c b/arch/arm/kvm/kvm_vfio_arm.c > new file mode 100644 > index 0000000..0d316b1 > --- /dev/null > +++ b/arch/arm/kvm/kvm_vfio_arm.c > @@ -0,0 +1,85 @@ > +/* > + * Copyright (C) 2014 Linaro Ltd. > + * Authors: Eric Auger <eric.auger@linaro.org> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License, version 2, as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + */ > + > +#include <linux/errno.h> > +#include <linux/file.h> > +#include <linux/kvm_host.h> > +#include <linux/list.h> > +#include <linux/mutex.h> > +#include <linux/vfio.h> > +#include <linux/irq.h> > +#include <asm/kvm_host.h> > +#include <asm/kvm.h> > +#include <linux/irq.h> > +#include <linux/platform_device.h> > +#include <linux/interrupt.h> > + > +/** > + * kvm_arch_set_fwd_state - change the forwarded state of an IRQ > + * @pfwd: the forwarded irq struct > + * @action: action to perform (set forward, set back normal, cleanup) > + * > + * programs the GIC and VGIC > + * returns the VGIC map/unmap return status > + * It is the responsability of the caller to make sure the physical IRQ responsibility > + * is not active. there is a critical section between the start of the There > + * VFIO IRQ handler and LR programming. Did we implement code to ensure this in the previous patch? I don't think I noticed it. Doesn't disabling the IRQ have the desired effect? a critical section? who are the contenders of this, what action should I take to make sure access to the critical section is serialized? > + */ > +int kvm_arch_set_fwd_state(struct kvm_fwd_irq *pfwd, > + enum kvm_fwd_irq_action action) > +{ > + int ret; > + struct irq_desc *desc = irq_to_desc(pfwd->hwirq); > + struct irq_data *d = &desc->irq_data; > + struct irq_chip *chip = desc->irq_data.chip; > + > + disable_irq(pfwd->hwirq); > + /* no fwd state change can happen if the IRQ is in progress */ > + if (irqd_irq_inprogress(d)) { > + kvm_err("%s cannot change fwd state (IRQ %d in progress\n", > + __func__, pfwd->hwirq); > + enable_irq(pfwd->hwirq); > + return -1; -1? seems like you're defining some new error code convenstions here. -EBUSY perhaps? probably want to use a goto label here as well. > + } > + > + if (action == KVM_VFIO_IRQ_SET_FORWARD) { > + irqd_set_irq_forwarded(d); > + ret = vgic_map_phys_irq(pfwd->vcpu, > + pfwd->gsi + VGIC_NR_PRIVATE_IRQS, > + pfwd->hwirq); > + } else if (action == KVM_VFIO_IRQ_SET_NORMAL) { > + irqd_clr_irq_forwarded(d); > + ret = vgic_unmap_phys_irq(pfwd->vcpu, > + pfwd->gsi + > + VGIC_NR_PRIVATE_IRQS, > + pfwd->hwirq); > + } else if (action == KVM_VFIO_IRQ_CLEANUP) { > + irqd_clr_irq_forwarded(d); > + /* > + * in case the guest did not complete the > + * virtual IRQ, let's do it for him. > + * when cleanup is called, VCPU have already > + * been freed, do not manipulate VGIC > + */ > + chip->irq_eoi(d); > + ret = 0; why can't you do this on SET_NORMAL? don't you also need to make sure the LR is unqueued from the VCPU and kick the VCPU? If there are hidden semantics that this should only ever be called when the VM is stopped (stopping) then that is not clear, and I think you need to just ahve the SET_NORMAL do the dirty work with a cleaner set of semantics. > + } else { > + enable_irq(pfwd->hwirq); you're enabling the irq twice now. > + ret = -EINVAL; > + } > + > + enable_irq(pfwd->hwirq); > + return ret; > +} > -- > 1.9.1 > Thanks, -Christoffer
WARNING: multiple messages have this Message-ID (diff)
From: christoffer.dall@linaro.org (Christoffer Dall) To: linux-arm-kernel@lists.infradead.org Subject: [RFC v2 9/9] KVM: KVM-VFIO: ARM forwarding control Date: Thu, 11 Sep 2014 05:10:32 +0200 [thread overview] Message-ID: <20140911031032.GJ2784@lvm> (raw) In-Reply-To: <1409575968-5329-10-git-send-email-eric.auger@linaro.org> On Mon, Sep 01, 2014 at 02:52:48PM +0200, Eric Auger wrote: > Enables forwarding control for ARM. By defining > __KVM_HAVE_ARCH_KVM_VFIO_FORWARD the patch enables > KVM_DEV_VFIO_DEVICE_FORWARD/UNFORWARD_IRQ command on ARM. As a > result it brings an optimized injection/completion handling for > forwarded IRQ. The ARM specific part is implemented in a new module, a new module ?!? you mean file, right? > kvm_vfio_arm.c > > Signed-off-by: Eric Auger <eric.auger@linaro.org> > --- > arch/arm/include/asm/kvm_host.h | 2 + > arch/arm/kvm/Makefile | 2 +- > arch/arm/kvm/kvm_vfio_arm.c | 85 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 88 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/kvm/kvm_vfio_arm.c > > diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h > index 1aee6bb..dfd3b05 100644 > --- a/arch/arm/include/asm/kvm_host.h > +++ b/arch/arm/include/asm/kvm_host.h > @@ -25,6 +25,8 @@ > #include <asm/fpstate.h> > #include <kvm/arm_arch_timer.h> > > +#define __KVM_HAVE_ARCH_KVM_VFIO_FORWARD > + > #if defined(CONFIG_KVM_ARM_MAX_VCPUS) > #define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS > #else > diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile > index ea1fa76..26a5a42 100644 > --- a/arch/arm/kvm/Makefile > +++ b/arch/arm/kvm/Makefile > @@ -19,7 +19,7 @@ kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o $(KVM)/vf > > obj-y += kvm-arm.o init.o interrupts.o > obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o > -obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o > +obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o kvm_vfio_arm.o > obj-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic.o > obj-$(CONFIG_KVM_ARM_VGIC) += $(KVM)/arm/vgic-v2.o > obj-$(CONFIG_KVM_ARM_TIMER) += $(KVM)/arm/arch_timer.o > diff --git a/arch/arm/kvm/kvm_vfio_arm.c b/arch/arm/kvm/kvm_vfio_arm.c > new file mode 100644 > index 0000000..0d316b1 > --- /dev/null > +++ b/arch/arm/kvm/kvm_vfio_arm.c > @@ -0,0 +1,85 @@ > +/* > + * Copyright (C) 2014 Linaro Ltd. > + * Authors: Eric Auger <eric.auger@linaro.org> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License, version 2, as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + */ > + > +#include <linux/errno.h> > +#include <linux/file.h> > +#include <linux/kvm_host.h> > +#include <linux/list.h> > +#include <linux/mutex.h> > +#include <linux/vfio.h> > +#include <linux/irq.h> > +#include <asm/kvm_host.h> > +#include <asm/kvm.h> > +#include <linux/irq.h> > +#include <linux/platform_device.h> > +#include <linux/interrupt.h> > + > +/** > + * kvm_arch_set_fwd_state - change the forwarded state of an IRQ > + * @pfwd: the forwarded irq struct > + * @action: action to perform (set forward, set back normal, cleanup) > + * > + * programs the GIC and VGIC > + * returns the VGIC map/unmap return status > + * It is the responsability of the caller to make sure the physical IRQ responsibility > + * is not active. there is a critical section between the start of the There > + * VFIO IRQ handler and LR programming. Did we implement code to ensure this in the previous patch? I don't think I noticed it. Doesn't disabling the IRQ have the desired effect? a critical section? who are the contenders of this, what action should I take to make sure access to the critical section is serialized? > + */ > +int kvm_arch_set_fwd_state(struct kvm_fwd_irq *pfwd, > + enum kvm_fwd_irq_action action) > +{ > + int ret; > + struct irq_desc *desc = irq_to_desc(pfwd->hwirq); > + struct irq_data *d = &desc->irq_data; > + struct irq_chip *chip = desc->irq_data.chip; > + > + disable_irq(pfwd->hwirq); > + /* no fwd state change can happen if the IRQ is in progress */ > + if (irqd_irq_inprogress(d)) { > + kvm_err("%s cannot change fwd state (IRQ %d in progress\n", > + __func__, pfwd->hwirq); > + enable_irq(pfwd->hwirq); > + return -1; -1? seems like you're defining some new error code convenstions here. -EBUSY perhaps? probably want to use a goto label here as well. > + } > + > + if (action == KVM_VFIO_IRQ_SET_FORWARD) { > + irqd_set_irq_forwarded(d); > + ret = vgic_map_phys_irq(pfwd->vcpu, > + pfwd->gsi + VGIC_NR_PRIVATE_IRQS, > + pfwd->hwirq); > + } else if (action == KVM_VFIO_IRQ_SET_NORMAL) { > + irqd_clr_irq_forwarded(d); > + ret = vgic_unmap_phys_irq(pfwd->vcpu, > + pfwd->gsi + > + VGIC_NR_PRIVATE_IRQS, > + pfwd->hwirq); > + } else if (action == KVM_VFIO_IRQ_CLEANUP) { > + irqd_clr_irq_forwarded(d); > + /* > + * in case the guest did not complete the > + * virtual IRQ, let's do it for him. > + * when cleanup is called, VCPU have already > + * been freed, do not manipulate VGIC > + */ > + chip->irq_eoi(d); > + ret = 0; why can't you do this on SET_NORMAL? don't you also need to make sure the LR is unqueued from the VCPU and kick the VCPU? If there are hidden semantics that this should only ever be called when the VM is stopped (stopping) then that is not clear, and I think you need to just ahve the SET_NORMAL do the dirty work with a cleaner set of semantics. > + } else { > + enable_irq(pfwd->hwirq); you're enabling the irq twice now. > + ret = -EINVAL; > + } > + > + enable_irq(pfwd->hwirq); > + return ret; > +} > -- > 1.9.1 > Thanks, -Christoffer
next prev parent reply other threads:[~2014-09-11 3:10 UTC|newest] Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-01 12:52 [RFC v2 0/9] KVM-VFIO IRQ forward control Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-01 12:52 ` [RFC v2 1/9] KVM: ARM: VGIC: fix multiple injection of level sensitive forwarded IRQ Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-11 3:09 ` Christoffer Dall 2014-09-11 3:09 ` Christoffer Dall 2014-09-11 18:17 ` Eric Auger 2014-09-11 18:17 ` Eric Auger 2014-09-11 22:14 ` Christoffer Dall 2014-09-11 22:14 ` Christoffer Dall 2014-09-01 12:52 ` [RFC v2 2/9] KVM: ARM: VGIC: add forwarded irq rbtree lock Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-11 3:09 ` Christoffer Dall 2014-09-11 3:09 ` Christoffer Dall 2014-09-11 17:31 ` Eric Auger 2014-09-11 17:31 ` Eric Auger 2014-09-01 12:52 ` [RFC v2 3/9] ARM: KVM: Enable the KVM-VFIO device Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-01 12:52 ` [RFC v2 4/9] VFIO: platform: handler tests whether the IRQ is forwarded Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 8:44 ` Eric Auger 2014-09-11 8:44 ` Eric Auger 2014-09-11 17:05 ` Christoffer Dall 2014-09-11 17:05 ` Christoffer Dall 2014-09-11 18:07 ` Alex Williamson 2014-09-11 18:07 ` Alex Williamson 2014-09-11 17:08 ` Antonios Motakis 2014-09-11 17:08 ` Antonios Motakis 2014-09-01 12:52 ` [RFC v2 5/9] KVM: KVM-VFIO: update user API to program forwarded IRQ Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 8:49 ` Eric Auger 2014-09-11 8:49 ` Eric Auger 2014-09-11 17:08 ` Christoffer Dall 2014-09-11 17:08 ` Christoffer Dall 2014-09-01 12:52 ` [RFC v2 6/9] VFIO: Extend external user API Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 8:50 ` Eric Auger 2014-09-11 8:50 ` Eric Auger 2014-09-01 12:52 ` [RFC v2 7/9] KVM: KVM-VFIO: add new VFIO external API hooks Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 8:51 ` Eric Auger 2014-09-11 8:51 ` Eric Auger 2014-09-01 12:52 ` [RFC v2 8/9] KVM: KVM-VFIO: generic KVM_DEV_VFIO_DEVICE command and IRQ forwarding control Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 5:05 ` Alex Williamson 2014-09-11 5:05 ` Alex Williamson 2014-09-11 5:05 ` Alex Williamson 2014-09-11 12:04 ` Eric Auger 2014-09-11 12:04 ` Eric Auger 2014-09-11 15:59 ` Alex Williamson 2014-09-11 15:59 ` Alex Williamson 2014-09-11 17:24 ` Christoffer Dall 2014-09-11 17:24 ` Christoffer Dall 2014-09-11 17:22 ` Christoffer Dall 2014-09-11 17:22 ` Christoffer Dall 2014-09-11 17:10 ` Christoffer Dall 2014-09-11 17:10 ` Christoffer Dall 2014-09-11 18:14 ` Alex Williamson 2014-09-11 18:14 ` Alex Williamson 2014-09-11 21:59 ` Christoffer Dall 2014-09-11 21:59 ` Christoffer Dall 2014-09-11 9:35 ` Eric Auger 2014-09-11 9:35 ` Eric Auger 2014-09-11 15:47 ` Alex Williamson 2014-09-11 15:47 ` Alex Williamson 2014-09-11 15:47 ` Alex Williamson 2014-09-11 17:32 ` Christoffer Dall 2014-09-11 17:32 ` Christoffer Dall 2014-09-01 12:52 ` [RFC v2 9/9] KVM: KVM-VFIO: ARM " Eric Auger 2014-09-01 12:52 ` Eric Auger 2014-09-11 3:10 ` Christoffer Dall [this message] 2014-09-11 3:10 ` Christoffer Dall 2014-09-02 21:05 ` [RFC v2 0/9] KVM-VFIO IRQ forward control Alex Williamson 2014-09-02 21:05 ` Alex Williamson 2014-09-05 12:52 ` Eric Auger 2014-09-05 12:52 ` Eric Auger 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 3:10 ` Christoffer Dall 2014-09-11 5:09 ` Alex Williamson 2014-09-11 5:09 ` Alex Williamson 2014-11-17 11:25 ` Wu, Feng 2014-11-17 11:25 ` Wu, Feng 2014-11-17 11:25 ` Wu, Feng 2014-11-17 13:41 ` Eric Auger 2014-11-17 13:41 ` Eric Auger 2014-11-17 13:41 ` Eric Auger 2014-11-17 13:45 ` Wu, Feng 2014-11-17 13:45 ` Wu, Feng 2014-11-17 13:45 ` Wu, Feng
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20140911031032.GJ2784@lvm \ --to=christoffer.dall@linaro.org \ --cc=a.motakis@virtualopensystems.com \ --cc=a.rigo@virtualopensystems.com \ --cc=alex.williamson@redhat.com \ --cc=eric.auger@linaro.org \ --cc=eric.auger@st.com \ --cc=gleb@kernel.org \ --cc=joel.schopp@amd.com \ --cc=john.liuli@huawei.com \ --cc=kim.phillips@freescale.com \ --cc=kvm@vger.kernel.org \ --cc=kvmarm@lists.cs.columbia.edu \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marc.zyngier@arm.com \ --cc=patches@linaro.org \ --cc=paulus@samba.org \ --cc=pbonzini@redhat.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.