search for: irqchip

...tries == 1) irqfd->irq_entry = *e; else irqfd->irq_entry.type = 0; Because any other value for irq_entry.type will just trigger schedule_work(&irqfd->inject). Please make it a separate patch, however. > @@ -471,6 +480,24 @@ void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin) > srcu_read_unlock(&kvm->irq_srcu, idx); > } > > +void kvm_notify_acked_hv_sint(struct kvm_vcpu *vcpu, u32 sint) > +{ > + struct kvm *kvm = vcpu->kvm; > + struct kvm_irq_ack_notifier *kian; > + int gsi, idx; > + > + vcpu_debug(vcpu, "...

...tries == 1) irqfd->irq_entry = *e; else irqfd->irq_entry.type = 0; Because any other value for irq_entry.type will just trigger schedule_work(&irqfd->inject). Please make it a separate patch, however. > @@ -471,6 +480,24 @@ void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin) > srcu_read_unlock(&kvm->irq_srcu, idx); > } > > +void kvm_notify_acked_hv_sint(struct kvm_vcpu *vcpu, u32 sint) > +{ > + struct kvm *kvm = vcpu->kvm; > + struct kvm_irq_ack_notifier *kian; > + int gsi, idx; > + > + vcpu_debug(vcpu, "...

On Mon, 12 Oct 2015 09:54:41 +0200 Christian Borntraeger <borntraeger at de.ibm.com> wrote: > Am 09.10.2015 um 16:42 schrieb Paolo Bonzini: > > Christian, the question for you is towards the end... > > > > [....] > > > >> --- a/virt/kvm/irqchip.c > >> +++ b/virt/kvm/irqchip.c > >> @@ -144,11 +144,13 @@ static int setup_routing_entry(struct kvm_irq_routing_table *rt, > >> > >> /* > >> * Do not allow GSI to be mapped to the same irqchip more than once. > >> - * Allow only one to...

On Mon, 12 Oct 2015 09:54:41 +0200 Christian Borntraeger <borntraeger at de.ibm.com> wrote: > Am 09.10.2015 um 16:42 schrieb Paolo Bonzini: > > Christian, the question for you is towards the end... > > > > [....] > > > >> --- a/virt/kvm/irqchip.c > >> +++ b/virt/kvm/irqchip.c > >> @@ -144,11 +144,13 @@ static int setup_routing_entry(struct kvm_irq_routing_table *rt, > >> > >> /* > >> * Do not allow GSI to be mapped to the same irqchip more than once. > >> - * Allow only one to...

Am 09.10.2015 um 16:42 schrieb Paolo Bonzini: > Christian, the question for you is towards the end... [....] > >> --- a/virt/kvm/irqchip.c >> +++ b/virt/kvm/irqchip.c >> @@ -144,11 +144,13 @@ static int setup_routing_entry(struct kvm_irq_routing_table *rt, >> >> /* >> * Do not allow GSI to be mapped to the same irqchip more than once. >> - * Allow only one to one mapping between GSI and MS...

This patchset implements the KVM part of the synthetic interrupt controller (synic) which is a building block of the Hyper-V paravirtualized device bus (vmbus). Synic is a lapic extension, which is controlled via MSRs and maintains for each vCPU - 16 synthetic interrupt "lines" (SINT's); each can be configured to trigger a specific interrupt vector optionally with auto-EOI

This patchset implements the KVM part of the synthetic interrupt controller (synic) which is a building block of the Hyper-V paravirtualized device bus (vmbus). Synic is a lapic extension, which is controlled via MSRs and maintains for each vCPU - 16 synthetic interrupt "lines" (SINT's); each can be configured to trigger a specific interrupt vector optionally with auto-EOI

...at virtuozzo.com> Signed-off-by: Denis V. Lunev <den at openvz.org> CC: Vitaly Kuznetsov <vkuznets at redhat.com> CC: "K. Y. Srinivasan" <kys at microsoft.com> CC: Gleb Natapov <gleb at kernel.org> CC: Paolo Bonzini <pbonzini at redhat.com> Changes v2: * irqchip/eventfd preparation improvements to support arch specific routing entries like Hyper-V SynIC ones. * add Hyper-V SynIC vectors into EOI exit bitmap. * do not use posted interrupts in case of Hyper-V SynIC AutoEOI vectors

...at virtuozzo.com> Signed-off-by: Denis V. Lunev <den at openvz.org> CC: Vitaly Kuznetsov <vkuznets at redhat.com> CC: "K. Y. Srinivasan" <kys at microsoft.com> CC: Gleb Natapov <gleb at kernel.org> CC: Paolo Bonzini <pbonzini at redhat.com> Changes v2: * irqchip/eventfd preparation improvements to support arch specific routing entries like Hyper-V SynIC ones. * add Hyper-V SynIC vectors into EOI exit bitmap. * do not use posted interrupts in case of Hyper-V SynIC AutoEOI vectors

...86/kvm/x86.c | 4 + drivers/hv/hyperv_vmbus.h | 5 - include/linux/kvm_host.h | 12 ++ include/uapi/linux/hyperv.h | 12 ++ include/uapi/linux/kvm.h | 8 ++ virt/kvm/arm/vgic.c | 18 +++ virt/kvm/eventfd.c | 35 +++++- virt/kvm/irqchip.c | 24 +++- 16 files changed, 475 insertions(+), 15 deletions(-) diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c index 6249cdc..01e7fb4 100644 --- a/arch/powerpc/kvm/mpic.c +++ b/arch/powerpc/kvm/mpic.c @@ -1850,3 +1850,21 @@ int kvm_set_routing_entry(struct kvm_kerne...

...e_iter, and .poll callbacks for the >>>>? chardev; they are used by the userspace to exchange IOTLB messages >>>> >>>>This patch was tested with QEMU and a patch applied [1] to fix a >>>>simple issue: >>>>??? $ qemu -M q35,accel=kvm,kernel-irqchip=split \ >>>>?????????? -drive file=fedora.qcow2,format=qcow2,if=virtio \ >>>>?????????? -device intel-iommu,intremap=on \ >>>>?????????? -device vhost-vsock-pci,guest-cid=3,iommu_platform=on >>> >>> >>>Patch looks good, but a question:...

...hose are not > > expected :)) > > > > The Google patches for userspace PIC and IOAPIC are proceeding well, so > > hopefully we can have interrupt remapping soon. > > If the day had 48 hours... I'd love to look into this, first adding QEMU > support for the new irqchip architecture. I hope I can squeeze in some time for that... Google also had an intern that was looking at it. Paolo

...hose are not > > expected :)) > > > > The Google patches for userspace PIC and IOAPIC are proceeding well, so > > hopefully we can have interrupt remapping soon. > > If the day had 48 hours... I'd love to look into this, first adding QEMU > support for the new irqchip architecture. I hope I can squeeze in some time for that... Google also had an intern that was looking at it. Paolo

...did the driver. The virtio-net driver depends on a transport driver to talk to the real device. Usually PCI is used as the transport for the device. In this case virtio-pci driver is in charge of dealing with irq allocation/free/configuration and it needs to co-operate with platform specific irqchip (virtualized by KVM) to finish the work like irq acknowledge etc.? E.g for x86, the irq offloading can only work when there's a hardware support of virtual irqchip (APICv) then all stuffs could be done without vmexits. So no vendor specific part since the device and transport are all standa...

On 28/07/2015 15:11, Jan Kiszka wrote: >>> >> >>> >> This doesn't matter much, since the only guests that implement an IOMMU >>> >> in QEMU are (afaik) PPC and x86, and x86 does not yet promise any kind >>> >> of stability. >> > >> > Hmm I think Jan (cc) said it was already used out there. > Yes, no known issues

On 28/07/2015 15:11, Jan Kiszka wrote: >>> >> >>> >> This doesn't matter much, since the only guests that implement an IOMMU >>> >> in QEMU are (afaik) PPC and x86, and x86 does not yet promise any kind >>> >> of stability. >> > >> > Hmm I think Jan (cc) said it was already used out there. > Yes, no known issues

Userspace patches for the pci-passthrough functionality. The major updates since the last post are: - Loop to add passthrough devices in pc_init1 - Handle errors in read/write calls - Allow invocation without irq number for in-kernel irqchip Other than this, several small things were fixed according to review comments received last time.

Userspace patches for the pci-passthrough functionality. The major updates since the last post are: - Loop to add passthrough devices in pc_init1 - Handle errors in read/write calls - Allow invocation without irq number for in-kernel irqchip Other than this, several small things were fixed according to review comments received last time.

...s MSIs there, or to a > system-wide GICv3 instance, and we need a way to select which one. Yes, agree. > > A degenerate case of this would be a system where a PCI device sends its MSI into > the host controller, that generates a legacy interrupt and that in turn gets > sent to an irqchip which turns it back into an MSI for the GICv3. This would of > course be very inefficient, but I think we should be able to express this with > both the binding and the in-kernel framework just to be on the safe side. Yes, the best way to tell the kernel which msi_chip should deliver to is d...

...s MSIs there, or to a > system-wide GICv3 instance, and we need a way to select which one. Yes, agree. > > A degenerate case of this would be a system where a PCI device sends its MSI into > the host controller, that generates a legacy interrupt and that in turn gets > sent to an irqchip which turns it back into an MSI for the GICv3. This would of > course be very inefficient, but I think we should be able to express this with > both the binding and the in-kernel framework just to be on the safe side. Yes, the best way to tell the kernel which msi_chip should deliver to is d...