| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1422416668.22865.91.camel@redhat.com> Date: Tue, 27 Jan 2015 20:44:28 -0700 From: Alex Williamson <alex.williamson@...hat.com> To: "Wu, Feng" <feng.wu@...el.com> Cc: "tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>, "gleb@...nel.org" <gleb@...nel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>, "dwmw2@...radead.org" <dwmw2@...radead.org>, "joro@...tes.org" <joro@...tes.org>, "jiang.liu@...ux.intel.com" <jiang.liu@...ux.intel.com>, "eric.auger@...aro.org" <eric.auger@...aro.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org> Subject: Re: [v3 00/26] Add VT-d Posted-Interrupts support On Wed, 2015-01-28 at 03:01 +0000, Wu, Feng wrote: > > > -----Original Message----- > > From: Wu, Feng > > Sent: Wednesday, January 21, 2015 10:26 AM > > To: tglx@...utronix.de; mingo@...hat.com; hpa@...or.com; x86@...nel.org; > > gleb@...nel.org; pbonzini@...hat.com; dwmw2@...radead.org; > > joro@...tes.org; alex.williamson@...hat.com; jiang.liu@...ux.intel.com > > Cc: eric.auger@...aro.org; linux-kernel@...r.kernel.org; > > iommu@...ts.linux-foundation.org; kvm@...r.kernel.org; Wu, Feng > > Subject: RE: [v3 00/26] Add VT-d Posted-Interrupts support > > > > > > > -----Original Message----- > > > From: Wu, Feng > > > Sent: Friday, December 12, 2014 11:15 PM > > > To: tglx@...utronix.de; mingo@...hat.com; hpa@...or.com; > > x86@...nel.org; > > > gleb@...nel.org; pbonzini@...hat.com; dwmw2@...radead.org; > > > joro@...tes.org; alex.williamson@...hat.com; jiang.liu@...ux.intel.com > > > Cc: eric.auger@...aro.org; linux-kernel@...r.kernel.org; > > > iommu@...ts.linux-foundation.org; kvm@...r.kernel.org; Wu, Feng > > > Subject: [v3 00/26] Add VT-d Posted-Interrupts support > > > > > > VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt. > > > With VT-d Posted-Interrupts enabled, external interrupts from > > > direct-assigned devices can be delivered to guests without VMM > > > intervention when guest is running in non-root mode. > > > > > > You can find the VT-d Posted-Interrtups Spec. in the following URL: > > > > > http://www.intel.com/content/www/us/en/intelligent-systems/intel-technolog > > > y/vt-directed-io-spec.html > > > > > > v1->v2: > > > * Use VFIO framework to enable this feature, the VFIO part of this series is > > > base on Eric's patch "[PATCH v3 0/8] KVM-VFIO IRQ forward control" > > > * Rebase this patchset on > > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git, > > > then revise some irq logic based on the new hierarchy irqdomain patches > > > provided > > > by Jiang Liu <jiang.liu@...ux.intel.com> > > > > > > v2->v3: > > > * Adjust the Posted-interrupts Descriptor updating logic when vCPU is > > > preempted or blocked. > > > * KVM_DEV_VFIO_DEVICE_POSTING_IRQ --> > > > KVM_DEV_VFIO_DEVICE_POST_IRQ > > > * __KVM_HAVE_ARCH_KVM_VFIO_POSTING --> > > > __KVM_HAVE_ARCH_KVM_VFIO_POST > > > * Add KVM_DEV_VFIO_DEVICE_UNPOST_IRQ attribute for VFIO irq, which > > > can be used to change back to remapping mode. > > > * Fix typo > > > > > > This patch series is made of the following groups: > > > 1-6: Some preparation changes in iommu and irq component, this is based on > > > the > > > new hierarchy irqdomain logic. > > > 7-9, 26: IOMMU changes for VT-d Posted-Interrupts, such as, feature > > > detection, > > > command line parameter. > > > 10-17, 22-25: Changes related to KVM itself. > > > 18-20: Changes in VFIO component, this part was previously sent out as > > > "[RFC PATCH v2 0/2] kvm-vfio: implement the vfio skeleton for VT-d > > > Posted-Interrupts" > > > 21: x86 irq related changes > > > > > > Feng Wu (26): > > > genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a > > > VCPU > > > iommu: Add new member capability to struct irq_remap_ops > > > iommu, x86: Define new irte structure for VT-d Posted-Interrupts > > > iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip > > > x86, irq: Implement irq_set_vcpu_affinity for pci_msi_ir_controller > > > iommu, x86: No need to migrating irq for VT-d Posted-Interrupts > > > iommu, x86: Add cap_pi_support() to detect VT-d PI capability > > > iommu, x86: Add intel_irq_remapping_capability() for Intel > > > iommu, x86: define irq_remapping_cap() > > > KVM: change struct pi_desc for VT-d Posted-Interrupts > > > KVM: Add some helper functions for Posted-Interrupts > > > KVM: Initialize VT-d Posted-Interrupts Descriptor > > > KVM: Define a new interface kvm_find_dest_vcpu() for VT-d PI > > > KVM: Get Posted-Interrupts descriptor address from struct kvm_vcpu > > > KVM: add interfaces to control PI outside vmx > > > KVM: Make struct kvm_irq_routing_table accessible > > > KVM: make kvm_set_msi_irq() public > > > KVM: kvm-vfio: User API for VT-d Posted-Interrupts > > > KVM: kvm-vfio: implement the VFIO skeleton for VT-d Posted-Interrupts > > > KVM: x86: kvm-vfio: VT-d posted-interrupts setup > > > x86, irq: Define a global vector for VT-d Posted-Interrupts > > > KVM: Define a wakeup worker thread for vCPU > > > KVM: Update Posted-Interrupts Descriptor when vCPU is preempted > > > KVM: Update Posted-Interrupts Descriptor when vCPU is blocked > > > KVM: Suppress posted-interrupt when 'SN' is set > > > iommu/vt-d: Add a command line parameter for VT-d posted-interrupts > > > > > > Documentation/kernel-parameters.txt | 1 + > > > Documentation/virtual/kvm/devices/vfio.txt | 9 ++ > > > arch/x86/include/asm/entry_arch.h | 2 + > > > arch/x86/include/asm/hardirq.h | 1 + > > > arch/x86/include/asm/hw_irq.h | 2 + > > > arch/x86/include/asm/irq_remapping.h | 11 ++ > > > arch/x86/include/asm/irq_vectors.h | 1 + > > > arch/x86/include/asm/kvm_host.h | 12 ++ > > > arch/x86/kernel/apic/msi.c | 1 + > > > arch/x86/kernel/entry_64.S | 2 + > > > arch/x86/kernel/irq.c | 27 ++++ > > > arch/x86/kernel/irqinit.c | 2 + > > > arch/x86/kvm/Makefile | 2 +- > > > arch/x86/kvm/kvm_vfio_x86.c | 77 +++++++++ > > > arch/x86/kvm/vmx.c | 244 > > > ++++++++++++++++++++++++++++- > > > arch/x86/kvm/x86.c | 22 ++- > > > drivers/iommu/intel_irq_remapping.c | 68 +++++++- > > > drivers/iommu/irq_remapping.c | 24 ++- > > > drivers/iommu/irq_remapping.h | 8 + > > > include/linux/dmar.h | 32 ++++ > > > include/linux/intel-iommu.h | 1 + > > > include/linux/irq.h | 7 + > > > include/linux/kvm_host.h | 46 ++++++ > > > include/uapi/linux/kvm.h | 11 ++ > > > kernel/irq/chip.c | 14 ++ > > > kernel/irq/manage.c | 20 +++ > > > virt/kvm/irq_comm.c | 43 ++++- > > > virt/kvm/irqchip.c | 11 -- > > > virt/kvm/kvm_main.c | 15 ++ > > > virt/kvm/vfio.c | 107 +++++++++++++ > > > 30 files changed, 795 insertions(+), 28 deletions(-) > > > create mode 100644 arch/x86/kvm/kvm_vfio_x86.c > > > > > > > Hi Paolo, Alex, and other maintainers, > > > > Since this series contain multiple subsystems, IOMMU, irq, x86, VFIO, KVM, etc. > > I am wondering how you guys handled this case before? If all the patches are > > reviewed and acked by the associated maintainer, are you only merge the > > patches > > related to your own subsystem to your tree? However, you may also need get > > other > > patches to make the build successful, so I am a little curious about how you guys > > handle this? Thanks a lot! > > Can anyone share some experiences about this? Generally you need to split the patches into logical changes per subsystem and submit them separately through the mailing list and maintainer. This helps to make sure the changes make sense and stand on their own and aren't simply a hack to reach the end goal. Submit what you can in parallel, but expect that if you send patches dependent on other, unmerged series, they will get ignored and will need to be resent when the dependencies are resolved in -next. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists