Re: [PATCH] use x86 cpu park to speedup smp_init in kexec situation

2021-01-07 Thread David Woodhouse
On Wed, 2020-12-16 at 16:31 +0100, Thomas Gleixner wrote: > But obviously the C-state in which the APs are waiting is not really > relevant, as you demonstrated that the cost is due to INIT/SIPI even > with spinwait, which is what I suspected. > > OTOH, the advantage of INIT/SIPI is that the AP

Re: 5.11-rc1 TTM list corruption

2021-01-06 Thread David Woodhouse
On Tue, 2021-01-05 at 16:40 +0100, Christian K├Ânig wrote: > Am 05.01.21 um 13:20 schrieb Huang Rui: > > On Tue, Jan 05, 2021 at 07:43:51PM +0800, Borislav Petkov wrote: > > > On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui wrote: > > > > Ah, this asic is a bit old and still use radeon driver.

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2021-01-05 Thread David Woodhouse
On Tue, 2021-01-05 at 12:11 +, Joao Martins wrote: > On 1/1/21 2:33 PM, David Woodhouse wrote: > > What it does actually mean in the short term is that as I update your > > KVM_IRQ_ROUTING_XEN_EVTCHN support, I probably *won't* bother to add a > > 'prio

[PATCH] iommu/amd: Stop irq_remapping_select() matching when remapping is disabled

2021-01-04 Thread David Woodhouse
From: David Woodhouse The AMD IOMMU initialisation registers the IRQ remapping domain for each IOMMU before doing the final sanity check that every I/OAPIC is covered. This means that the AMD irq_remapping_select() function gets invoked even when IRQ remapping has been disabled, eventually

[PATCH] iommu/amd: Set iommu->int_enabled consistently when interrupts are set up

2021-01-04 Thread David Woodhouse
From: David Woodhouse When I made the INTCAPXT support stop gratuitously pretending to be MSI, I missed the fact that iommu_setup_msi() also sets the ->int_enabled flag. I missed this in the iommu_setup_intcapxt() code path, which means that a resume from suspend will try to allocate the

Re: [EXTERNAL] PROBLEM: commit f36a74b9345a leads to not booting system with AMD 2990WX

2021-01-04 Thread David Woodhouse
On Tue, 2021-01-05 at 00:05 +0100, Johnathan Smithinovic wrote: > commit f36a74b9345a leads to not booting system with AMD 2990WX > > > When trying to boot 5.11-rc2 as usual the messages of the bootloader stay on > my > screen and not much appears to happen (fans run a bit slower than in GRUB,

Re: Interrupts enabled after amd_iommu_resume+0x0/0x40

2021-01-04 Thread David Woodhouse
On Tue, 2021-01-05 at 00:23 +0100, Borislav Petkov wrote: > On Mon, Jan 04, 2021 at 02:22:50PM +0100, Borislav Petkov wrote: > > Hi folks, > > > > syscore_resume() doesn't like when the AMD iommu driver enables > > interrupts in its ->resume hook when I resume the box from suspend to > > RAM. > >

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2021-01-01 Thread David Woodhouse
On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote: > > But if the kernel is going to short-circuit the IPIs and VIRQs, then > > it's already going to have to handle the evtchn_pending/evtchn_mask > > bitmaps, and actually injecting interrupts. > > > > Right. I was trying to point that out in

Re: [KVM] fdd90b978b: WARNING:suspicious_RCU_usage

2020-12-22 Thread David Woodhouse
On Tue, 2020-12-22 at 13:06 +0800, kernel test robot wrote: > > kern :warn : [ 86.138096] WARNING: suspicious RCU usage > kern :warn : [ 86.142286] 5.10.0-rc5-gfdd90b978b4e #1 Tainted: G > I > kern :warn : [ 86.148879] - > kern :warn : [

Re: [PATCH RFC 03/39] KVM: x86/xen: register shared_info page

2020-12-12 Thread David Woodhouse
On Tue, 2020-12-01 at 16:40 -0800, Ankur Arora wrote: > > How come we get to pin the page and directly dereference it every time, > > while kvm_setup_pvclock_page() has to use kvm_write_guest_cached() > > instead? > > So looking at my WIP trees from the time, this is something that > we went back

Re: [RFC PATCH 1/1] platform-msi: Add platform check for subdevice irq domain

2020-12-10 Thread David Woodhouse
On Thu, 2020-12-10 at 12:57 -0600, Bjorn Helgaas wrote: > What is the point of a function called probably_on_bare_metal()? > *Probably*? The caller can't really do anything with the fact that > we're not 100% sure this gives the correct answer. Just call it > "on_bare_metal()" or something and

Re: [RFC PATCH 1/1] platform-msi: Add platform check for subdevice irq domain

2020-12-10 Thread David Woodhouse
On Thu, 2020-12-10 at 08:46 +0800, Lu Baolu wrote: > +/* > + * We want to figure out which context we are running in. But the hardware > + * does not introduce a reliable way (instruction, CPUID leaf, MSR, whatever) > + * which can be manipulated by the VMM to let the OS figure out where it >

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2020-12-09 Thread David Woodhouse
On 9 December 2020 13:26:55 GMT, Joao Martins wrote: >On 12/9/20 11:39 AM, David Woodhouse wrote: >> On Wed, 2020-12-09 at 10:51 +, Joao Martins wrote: >>> Isn't this what the first half of this patch was doing initially >(minus the >>> irq routing) ? Looks

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2020-12-09 Thread David Woodhouse
On Wed, 2020-12-09 at 10:51 +, Joao Martins wrote: > Isn't this what the first half of this patch was doing initially (minus the > irq routing) ? Looks really similar: > > https://lore.kernel.org/kvm/20190220201609.28290-11-joao.m.mart...@oracle.com/ Absolutely! This thread is in reply to

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2020-12-09 Thread David Woodhouse
On Tue, 2020-12-08 at 22:35 -0800, Ankur Arora wrote: > > It looks like Linux doesn't use the per-vCPU upcall vector that you > > called 'KVM_XEN_CALLBACK_VIA_EVTCHN'. So I'm delivering interrupts via > > KVM_INTERRUPT as if they were ExtINT > > > > ... except I'm not. Because the kernel

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2020-12-08 Thread David Woodhouse
On Wed, 2020-12-02 at 19:02 +, David Woodhouse wrote: > > > I feel we could just accommodate it as subtype in > > KVM_XEN_ATTR_TYPE_CALLBACK_VIA. > > Don't see the adavantage in having another xen attr type. > > Yeah, fair enough. > > > But kinda

Re: [PATCH RFC 03/39] KVM: x86/xen: register shared_info page

2020-12-03 Thread David Woodhouse
On Wed, 2020-12-02 at 12:32 -0800, Ankur Arora wrote: > > On IRC, Paolo told me that permanent pinning causes problems for memory > > hotplug, and pointed me at the trick we do with an MMU notifier and > > kvm_vcpu_reload_apic_access_page(). > > Okay that answers my question. Thanks for clearing

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2020-12-02 Thread David Woodhouse
On Wed, 2020-12-02 at 20:12 +, Joao Martins wrote: > > I'll do some more experiments and > > see what I can get working, and what it looks like. > > > > I'm focusing on making the shinfo stuff all use kvm_map_gfn() first. > > > > I was chatting with Ankur, and we can't fully 100% remember

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2020-12-02 Thread David Woodhouse
On Wed, 2020-12-02 at 18:34 +, Joao Martins wrote: > On 12/2/20 4:47 PM, David Woodhouse wrote: > > On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote: > > > On 12/2/20 11:17 AM, David Woodhouse wrote: > > > > I might be more inclined to go for a

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2020-12-02 Thread David Woodhouse
On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote: > On 12/2/20 11:17 AM, David Woodhouse wrote: > > I might be more inclined to go for a model where the kernel handles the > > evtchn_pending/evtchn_mask for us. What would go into the irq routing > > table is { vcpu, por

Re: [PATCH RFC 03/39] KVM: x86/xen: register shared_info page

2020-12-02 Thread David Woodhouse
On Wed, 2020-12-02 at 10:44 +, Joao Martins wrote: > [late response - was on holiday yesterday] > > On 12/2/20 12:40 AM, Ankur Arora wrote: > > On 2020-12-01 5:07 a.m., David Woodhouse wrote: > > > On Wed, 2019-02-20 at 20:15 +, Joao Martins wr

Re: [PATCH RFC 02/39] KVM: x86/xen: intercept xen hypercalls if enabled

2020-12-02 Thread David Woodhouse
On Wed, 2020-12-02 at 11:17 +, Joao Martins wrote: > Xen viridian mode is indeed one thing that needed fixing. And definitely a > separate patch as you do here. Both this one and the previous is looking good. > > I suppose that because you switch to kvm_vcpu_write_guest() you no longer need >

Re: [PATCH RFC 10/39] KVM: x86/xen: support upcall vector

2020-12-02 Thread David Woodhouse
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote: > @@ -176,6 +177,9 @@ int kvm_arch_set_irq_inatomic(struct > kvm_kernel_irq_routing_entry *e, > int r; > > switch (e->type) { > + case KVM_IRQ_ROUTING_XEN_EVTCHN: > + return kvm_xen_set_evtchn(e, kvm,

Re: [PATCH RFC 02/39] KVM: x86/xen: intercept xen hypercalls if enabled

2020-12-02 Thread David Woodhouse
On Tue, 2020-12-01 at 21:19 -0800, Ankur Arora wrote: > > + for (i = 0; i < PAGE_SIZE / sizeof(instructions); i++) { > > + *(u32 *)[1] = i; > > + if (kvm_vcpu_write_guest(vcpu, > > + page_addr + (i *

Re: [PATCH RFC 03/39] KVM: x86/xen: register shared_info page

2020-12-01 Thread David Woodhouse
On Tue, 2020-12-01 at 16:40 -0800, Ankur Arora wrote: > On 2020-12-01 5:07 a.m., David Woodhouse wrote: > > On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote: > > > +static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn) > > > +{ > > > +

Re: [PATCH RFC 03/39] KVM: x86/xen: register shared_info page

2020-12-01 Thread David Woodhouse
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote: > +static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn) > +{ > + struct shared_info *shared_info; > + struct page *page; > + > + page = gfn_to_page(kvm, gfn); > + if (is_error_page(page)) > +

Re: [PATCH RFC 02/39] KVM: x86/xen: intercept xen hypercalls if enabled

2020-12-01 Thread David Woodhouse
On Tue, 2020-12-01 at 09:48 +, David Woodhouse wrote: > So I switched it to generate the hypercall page directly from the > kernel, just like we do for the Hyper-V hypercall page. Speaking of Hyper-V... I'll post this one now so you can start heckling it. I won't post the rest a

Re: [PATCH] x86, build: remove -m16 workaround for unsupported versions of GCC

2020-12-01 Thread David Woodhouse
bly header") > > Since commit 0bddd227f3dc ("Documentation: update for gcc 4.9 > requirement") the minimum supported version of GCC is gcc-4.9. It's now > safe to remove this code. > > Signed-off-by: Nick Desaulniers Reviewed-by: David Woodhouse smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH RFC 02/39] KVM: x86/xen: intercept xen hypercalls if enabled

2020-12-01 Thread David Woodhouse
CALL flag in the KVM_XEN_HVM_CONFIG ioctl structure, and advertised by the same flag being returned from the KVM_CAP_XEN_HVM check. Add a test case and shift xen_hvm_config() to the nascent xen.c while we're at it. Signed-off-by: Joao Martins Signed-off-by: David Woodhouse --- arch/x86/include/asm/k

Re: [PATCH RFC 11/39] KVM: x86/xen: evtchn signaling via eventfd

2020-11-30 Thread David Woodhouse
On Mon, 2020-11-30 at 18:41 +, Joao Martins wrote: > int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) > { > ... > if (kvm_hv_hypercall_enabled(vcpu->kvm)) > return kvm_hv_hypercall(...); > > if (kvm_xen_hypercall_enabled(vcpu->kvm)) > return

Re: [PATCH RFC 11/39] KVM: x86/xen: evtchn signaling via eventfd

2020-11-30 Thread David Woodhouse
On Mon, 2020-11-30 at 17:15 +, Joao Martins wrote: > On 11/30/20 4:48 PM, David Woodhouse wrote: > > On Mon, 2020-11-30 at 15:08 +, Joao Martins wrote: > > > On 11/30/20 12:55 PM, David Woodhouse wrote: > > > > On Mon, 2020-11-30 at 12:17 +, Joao Martins

Re: [PATCH RFC 11/39] KVM: x86/xen: evtchn signaling via eventfd

2020-11-30 Thread David Woodhouse
On Mon, 2020-11-30 at 15:08 +, Joao Martins wrote: > On 11/30/20 12:55 PM, David Woodhouse wrote: > > On Mon, 2020-11-30 at 12:17 +, Joao Martins wrote: > > > On 11/30/20 9:41 AM, David Woodhouse wrote: > > > > On Wed, 2019-02-20 at 20:15 +, Joao Martins w

Re: [PATCH RFC 11/39] KVM: x86/xen: evtchn signaling via eventfd

2020-11-30 Thread David Woodhouse
On Mon, 2020-11-30 at 12:17 +, Joao Martins wrote: > On 11/30/20 9:41 AM, David Woodhouse wrote: > > On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote: > > > userspace registers a @port to an @eventfd, that is bound to a > > > @vcpu. This information is th

Re: [PATCH RFC 01/39] KVM: x86: fix Xen hypercall page msr handling

2020-11-30 Thread David Woodhouse
On Mon, 2020-11-30 at 12:03 +0100, Paolo Bonzini wrote: > You can use CPUID too (search for Hv#1 in leaf 0x4000)? That's leaf 0x4001. Which is also the leaf used for Xen to indicate the Xen version. So as long as we don't pretend to be Xen version 12759.30280 I suppose that's OK. Or we

Re: [PATCH RFC 01/39] KVM: x86: fix Xen hypercall page msr handling

2020-11-30 Thread David Woodhouse
config.msr == HV_X64_MSR_GUEST_OS_ID. But that's basically what Joao's patch already does. It doesn't disable the *other* Hyper-V MSRs except for the one Xen 'conflicts' with, but I don't think that matters. The patch stands alone to correct the *existing* functionality of KVM_XEN_HVM_CONFIG,

Re: [PATCH RFC 11/39] KVM: x86/xen: evtchn signaling via eventfd

2020-11-30 Thread David Woodhouse
On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote: > userspace registers a @port to an @eventfd, that is bound to a > @vcpu. This information is then used when the guest does an > EVTCHNOP_send with a port registered with the kernel. Why do I want this part? > EVTCHNOP_send short-circuiting

Re: [PATCH 0/2] KVM: x86: cleanup and fix userspace interrupt window

2020-11-27 Thread David Woodhouse
exception of the stray apostrophe already noted, both: Reviewed-by: David Woodhouse Tested-by: David Woodhouse There is a slight caveat that I think we're accepting ExtINT from userspace PIC sooner than we should, and queuing it up for delivery in the kernel. Whereas real hardware might not issue the I

Re: [PATCH 1/2] KVM: x86: handle !lapic_in_kernel case in kvm_cpu_*_extint

2020-11-27 Thread David Woodhouse
On Fri, 2020-11-27 at 06:21 -0500, Paolo Bonzini wrote: > +* FIXME: interrupt.injected represents an interrupt that it's You can drop the stray apostrophe from that "its" while you're moving it... smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH v3 12/17] asm-generic/hyperv: update hv_interrupt_entry

2020-11-24 Thread David Woodhouse
On Tue, 2020-11-24 at 17:07 +, Wei Liu wrote: > We will soon use the same structure to handle IO-APIC interrupts as > well. Introduce an enum to identify the source and a data structure for > IO-APIC RTE. > > While at it, update pci-hyperv.c to use the enum. > > No functional change. > >

[tip: x86/apic] iommu/amd: Fix IOMMU interrupt generation in X2APIC mode

2020-11-18 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: d1adcfbb520c43c10fc22fcdccdd4204e014fb53 Gitweb: https://git.kernel.org/tip/d1adcfbb520c43c10fc22fcdccdd4204e014fb53 Author:David Woodhouse AuthorDate:Wed, 11 Nov 2020 12:09:01 Committer

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-18 Thread David Woodhouse
On Wed, 2020-11-18 at 23:51 +0700, Suravee Suthikulpanit wrote: > Yes, this fixes the issue. Now I can receive the IOMMU event log > interrupts for IO_PAGE_FAULT event, which is triggered > using the injection interface via debugfs. Thanks, Suravee. smime.p7s Description: S/MIME cryptographic

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-18 Thread David Woodhouse
On Wed, 2020-11-18 at 17:29 +0700, Suravee Suthikulpanit wrote: > I might need your help debugging this issue. I'm seeing the following error: > > [ 14.005937] irq 29, desc: d200500b, depth: 0, count: 0, unhandled: > 0 > [ 14.006234] ->handle_irq(): eab4b6eb,

Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks

2020-11-17 Thread David Woodhouse
On Tue, 2020-11-17 at 10:53 +0100, Thomas Gleixner wrote: > But that does not solve the problem either simply because then the IOMMU > will catch the rogue MSIs and you get an interrupt storm on the IOMMU > error interrupt. Not if you can tell the IOMMU to stop reporting those errors. We can

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-16 Thread David Woodhouse
On Fri, 2020-11-13 at 15:14 +, David Woodhouse wrote: > On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote: > > I had trouble cloning your tree for some reason, so just took the top > > three patches and applied them to the tip tree. This all appears to be > > workin

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-13 Thread David Woodhouse
ee Thomas has taken the first two into the tip.git x86/apic branch already, so we're just looking for an ack on the third. Which is this one... From 49ee4fa51b8c06d14b7c4c74d15a7d76f865a8ea Mon Sep 17 00:00:00 2001 From: David Woodhouse Date: Wed, 11 Nov 2020 12:09:01 + Subject: [PATCH] iommu

[tip: x86/apic] iommu/amd: Fix union of bitfields in intcapxt support

2020-11-11 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 2fb6acf3edfeb904505f9ba3fd01166866062591 Gitweb: https://git.kernel.org/tip/2fb6acf3edfeb904505f9ba3fd01166866062591 Author:David Woodhouse AuthorDate:Wed, 11 Nov 2020 14:43:21 Committer

[tip: x86/apic] iommu/amd: Don't register interrupt remapping irqdomain when IR is disabled

2020-11-11 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 2df985f5e44c43f5d29d8cc3aaa8e8ac697e9de6 Gitweb: https://git.kernel.org/tip/2df985f5e44c43f5d29d8cc3aaa8e8ac697e9de6 Author:David Woodhouse AuthorDate:Wed, 11 Nov 2020 14:43:20 Committer

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-11 Thread David Woodhouse
On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote: > On 11/11/20 6:32 AM, David Woodhouse wrote: > > On Wed, 2020-11-11 at 10:36 +0000, David Woodhouse wrote: > > > On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote: > > > > Looking at it now with brain aw

[PATCH 3/3] iommu/amd: Fix IOMMU interrupt generation in X2APIC mode

2020-11-11 Thread David Woodhouse
From: David Woodhouse The AMD IOMMU has two modes for generating its own interrupts. The first is very much based on PCI MSI, and can be configured by Linux precisely that way. But like legacy unmapped PCI MSI it's limited to 8 bits of APIC ID. The second method does not use PCI MSI at all

[PATCH 2/3] iommu/amd: Fix union of bitfields in intcapxt support

2020-11-11 Thread David Woodhouse
From: David Woodhouse All the bitfields in here are overlaid on top of each other since they're a union. Change the second u64 to be in a struct so it does the intended thing. Fixes: b5c3786ee3704 ("iommu/amd: Use msi_msg shadow structs") Signed-off-by: David Woodhouse --- drivers

[PATCH 1/3] iommu/amd: Don't register interrupt remapping irqdomain when IR is disabled

2020-11-11 Thread David Woodhouse
From: David Woodhouse This was potentially allowing I/OAPIC and MSI interrupts to be parented in the IOMMU IR domain even when IR was disabled. Don't do that. Signed-off-by: David Woodhouse --- drivers/iommu/amd/init.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-11 Thread David Woodhouse
On Wed, 2020-11-11 at 10:36 +, David Woodhouse wrote: > On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote: > > Looking at it now with brain awake, the XTSUP stuff is pretty much > > the same as DMAR, which I didn't realize yesterday. The affinity > > notifier muck

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-11 Thread David Woodhouse
On Wed, 2020-11-11 at 10:46 +0100, Thomas Gleixner wrote: > Looking at it now with brain awake, the XTSUP stuff is pretty much > the same as DMAR, which I didn't realize yesterday. The affinity > notifier muck is not needed when we have a write_msg() function which > twiddles the bits into those

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-11 Thread David Woodhouse
On Tue, 2020-11-10 at 23:48 +0100, Thomas Gleixner wrote: > + * IRQCHIP_MSI_EXTID The MSI message created for this chip > can > + * have an otherwise forbidden extended ID If we're going to do that then we could ditch the separate

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-10 Thread David Woodhouse
On 10 November 2020 21:01:17 GMT, Thomas Gleixner wrote: >On Tue, Nov 10 2020 at 19:21, David Woodhouse wrote: > >> On 10 November 2020 18:56:17 GMT, Thomas Gleixner > wrote: >>>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote: >>>> On Tue, Nov 10

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-10 Thread David Woodhouse
On 10 November 2020 18:56:17 GMT, Thomas Gleixner wrote: >On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote: >> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote: >>> If I could get post-5.5 kernels to boot at all with the AMD IOMMU >>> enabled, I'd have a go at

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-10 Thread David Woodhouse
On Tue, 2020-11-10 at 10:17 -0600, Tom Lendacky wrote: > Yep. The warning started triggering with: > 47bea873cf80 ("x86/msi: Only use high bits of MSI address for DMAR unit") > > Here's the backtrace: > > [ 15.611109] [ cut here ] > [ 15.616274] WARNING: CPU: 184 PID:

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-10 Thread David Woodhouse
On Tue, 2020-11-10 at 16:54 +0100, Thomas Gleixner wrote: > On Tue, Nov 10 2020 at 08:55, Tom Lendacky wrote: > > On 11/10/20 8:34 AM, Thomas Gleixner wrote: > > I was about to send the dmesg output when I saw this. A quick test > > with > > this change resolves the boot issue, thanks! > > /me

Re: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection

2020-11-10 Thread David Woodhouse
> Hi David > > I did't follow the support for 32768 CPUs in guest without IR support. > > Can you tell me how that is done? Using bits 11-5 of the MSI address bits (the other 7 bits of "Extended Destination ID" that aren't the Remappable Format indicator). And physical addressing mode,

Re: [PATCH v3 19/35] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-10 Thread David Woodhouse
On Tue, 2020-11-10 at 01:31 -0500, Qian Cai wrote: > On Sat, 2020-10-24 at 22:35 +0100, David Woodhouse wrote: > > From: Thomas Gleixner > > > > 'trigger' and 'polarity' are used throughout the I/O-APIC code for handling > > the trigger type (edge/level) and the ac

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-09 Thread David Woodhouse
On Mon, 2020-11-09 at 17:15 -0600, Tom Lendacky wrote: > On 10/29/20 7:15 AM, tip-bot2 for Thomas Gleixner wrote: > > The following commit has been merged into the x86/apic branch of tip: > > > > Commit-ID: a27dca645d2c0f31abb7858aa0e10b2fa0f2f659 > > Gitweb: > >

Re: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection

2020-11-08 Thread David Woodhouse
> On Fri, Nov 06 2020 at 09:14, Jason Gunthorpe wrote: >> On Fri, Nov 06, 2020 at 09:48:34AM +, Tian, Kevin wrote: >> For instance you could put a "disable IMS" flag in the ACPI tables, in >> the config space of the emuulated root port, or any other areas that >> clearly belong to the

Re: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection

2020-11-08 Thread David Woodhouse
On Sun, 2020-11-08 at 19:47 +0100, Thomas Gleixner wrote: > This only works when the guest OS actually knows that it runs in a > VM. If the guest can't figure that out, i.e. via CPUID, this cannot be > solved because from the guest OS view that's the same as running on bare > metal. Obviously on

Re: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection

2020-11-08 Thread David Woodhouse
On Sun, 2020-11-08 at 10:11 -0800, Raj, Ashok wrote: > Hi Jason > > Thanks, its now clear what you had mentioned earlier. > > I had couple questions/clarifications below. Thanks for working > through this. > > On Fri, Nov 06, 2020 at 08:12:07PM -0400, Jason Gunthorpe wrote: > > On Fri, Nov 06,

Re: [PATCH v2 1/2] sched/wait: Add add_wait_queue_priority()

2020-11-06 Thread David Woodhouse
On 6 November 2020 16:32:00 GMT, Alex Williamson wrote: >On Fri, 6 Nov 2020 11:17:21 +0100 >Paolo Bonzini wrote: > >> On 04/11/20 10:35, David Woodhouse wrote: >> > On Wed, 2020-10-28 at 15:35 +0100, Peter Zijlstra wrote: >> >> On Tue, Oct 27, 2020

[tip: x86/apic] x86/ioapic: Use I/O-APIC ID for finding irqdomain, not index

2020-11-04 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: f36a74b9345aebaf5d325380df87a54720229d18 Gitweb: https://git.kernel.org/tip/f36a74b9345aebaf5d325380df87a54720229d18 Author:David Woodhouse AuthorDate:Tue, 03 Nov 2020 16:36:22 Committer

Re: [PATCH v2 1/2] sched/wait: Add add_wait_queue_priority()

2020-11-04 Thread David Woodhouse
On Wed, 2020-10-28 at 15:35 +0100, Peter Zijlstra wrote: > On Tue, Oct 27, 2020 at 02:39:43PM +0000, David Woodhouse wrote: > > From: David Woodhouse > > > > This allows an exclusive wait_queue_entry to be added at the head of the > > queue, instead of the ta

[PATCH] x86/ioapic: Use I/OAPIC ID for finding irqdomain, not index

2020-11-03 Thread David Woodhouse
From: David Woodhouse In commit b643128b917 ("x86/ioapic: Use irq_find_matching_fwspec() to find remapping irqdomain") the I/OAPIC code was changed to find its parent irqdomain using irq_find_matching_fwspec(), but the key used for the lookup was wrong. It shouldn't use 'ioa

Re: [PATCH] x86/hyperv: Enable 15-bit APIC ID if the hypervisor supports it

2020-11-03 Thread David Woodhouse
255 APIC ID. > > The kdump issue can be fixed by the Extended Dest ID, which is introduced > recently by David Woodhouse (for IOAPIC, see the field virt_destid_8_14 in > struct IO_APIC_route_entry). Of course, the Extended Dest ID needs the > support of the underlying hypervisor. The

[tip: x86/apic] x86/kvm: Enable 15-bit extension when KVM_FEATURE_MSI_EXT_DEST_ID detected

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 2e008ffe426f927b1697adb4ed10c1e419927ae4 Gitweb: https://git.kernel.org/tip/2e008ffe426f927b1697adb4ed10c1e419927ae4 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:35 +01:00

[tip: x86/apic] iommu/vt-d: Implement select() method on remapping irqdomain

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: a87fb465ffe8eacd0d69032da33455e4f6fd8b41 Gitweb: https://git.kernel.org/tip/a87fb465ffe8eacd0d69032da33455e4f6fd8b41 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:25 +01:00

[tip: x86/apic] iommu/hyper-v: Disable IRQ pseudo-remapping if 15 bit APIC IDs are available

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: bf27ef8a77d8da38c9f35f8f6aab013a2dcf175f Gitweb: https://git.kernel.org/tip/bf27ef8a77d8da38c9f35f8f6aab013a2dcf175f Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:33 +01:00

[tip: x86/apic] x86/ioapic: Generate RTE directly from parent irqchip's MSI message

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 5d5a97133887b2dfd8e2ad0347c3a02cc7aaa0cb Gitweb: https://git.kernel.org/tip/5d5a97133887b2dfd8e2ad0347c3a02cc7aaa0cb Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:21 +01:00

[tip: x86/apic] iommu/amd: Implement select() method on remapping irqdomain

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: a1a785b572425ab3ca5494a4be02ab59a796df51 Gitweb: https://git.kernel.org/tip/a1a785b572425ab3ca5494a4be02ab59a796df51 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:24 +01:00

[tip: x86/apic] x86/ioapic: Handle Extended Destination ID field in RTE

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 51130d21881d435fad5fa7f25bea77aa0ffc9a4e Gitweb: https://git.kernel.org/tip/51130d21881d435fad5fa7f25bea77aa0ffc9a4e Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:31 +01:00

[tip: x86/apic] x86/ioapic: Use irq_find_matching_fwspec() to find remapping irqdomain

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: b643128b917ca8f1c8b1e14af64ebdc81147b2d1 Gitweb: https://git.kernel.org/tip/b643128b917ca8f1c8b1e14af64ebdc81147b2d1 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:28 +01:00

[tip: x86/apic] x86/apic: Add select() method on vector irqdomain

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 6452ea2a323b80868ce5e6d3030e4ccbeab9dc30 Gitweb: https://git.kernel.org/tip/6452ea2a323b80868ce5e6d3030e4ccbeab9dc30 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:23 +01:00

[tip: x86/apic] genirq/irqdomain: Implement get_name() method on irqchip fwnodes

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 2cbd5a45e5296b28d64224ffbbd33d427704ba1b Gitweb: https://git.kernel.org/tip/2cbd5a45e5296b28d64224ffbbd33d427704ba1b Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:22 +01:00

[tip: x86/apic] x86/kvm: Reserve KVM_FEATURE_MSI_EXT_DEST_ID

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 5a169bf04cd2bfdbac967d12eb5b70915b29d7ee Gitweb: https://git.kernel.org/tip/5a169bf04cd2bfdbac967d12eb5b70915b29d7ee Author:David Woodhouse AuthorDate:Mon, 19 Oct 2020 15:55:56 +01:00

[tip: x86/apic] x86/hpet: Move MSI support into hpet.c

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 3d7295eb3003aea9f89de35304b3a88ae4d5036b Gitweb: https://git.kernel.org/tip/3d7295eb3003aea9f89de35304b3a88ae4d5036b Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:10 +01:00

[tip: x86/apic] x86/apic: Always provide irq_compose_msi_msg() method for vector domain

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: f598181acfb36f67e1de138cbe80a7db497f7d8c Gitweb: https://git.kernel.org/tip/f598181acfb36f67e1de138cbe80a7db497f7d8c Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:09 +01:00

[tip: x86/apic] x86/msi: Only use high bits of MSI address for DMAR unit

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 47bea873cf809f490cfac0c4e88533fd7fed6064 Gitweb: https://git.kernel.org/tip/47bea873cf809f490cfac0c4e88533fd7fed6064 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:02 +01:00

[tip: x86/apic] x86/apic: Fix x2apic enablement without interrupt remapping

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 26573a97746c7a99f394f9d398ce91a8853b3b89 Gitweb: https://git.kernel.org/tip/26573a97746c7a99f394f9d398ce91a8853b3b89 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:01 +01:00

[tip: x86/apic] x86/hpet: Use irq_find_matching_fwspec() to find remapping irqdomain

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: c2a5881c28e5bb4cb901029423a1c7068c0afa2d Gitweb: https://git.kernel.org/tip/c2a5881c28e5bb4cb901029423a1c7068c0afa2d Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:27 +01:00

[tip: x86/apic] x86/apic: Support 15 bits of APIC ID in MSI where available

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: ab0f59c6f135289c7ea90b0e2471674bf289d884 Gitweb: https://git.kernel.org/tip/ab0f59c6f135289c7ea90b0e2471674bf289d884 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:32 +01:00

[tip: x86/apic] iommu/hyper-v: Implement select() method on remapping irqdomain

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: a491bb19f728cdb8cc1f4734ecc57c0afa099fac Gitweb: https://git.kernel.org/tip/a491bb19f728cdb8cc1f4734ecc57c0afa099fac Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:26 +01:00

[tip: x86/apic] iommu/vt-d: Simplify intel_irq_remapping_select()

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: 79eb3581bcaae9b5677629d945e14da212aa76e2 Gitweb: https://git.kernel.org/tip/79eb3581bcaae9b5677629d945e14da212aa76e2 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:30 +01:00

[tip: x86/apic] x86: Kill all traces of irq_remapping_get_irq_domain()

2020-10-29 Thread tip-bot2 for David Woodhouse
The following commit has been merged into the x86/apic branch of tip: Commit-ID: ed381fca47122f0787ee53b97e5f9d562eec7237 Gitweb: https://git.kernel.org/tip/ed381fca47122f0787ee53b97e5f9d562eec7237 Author:David Woodhouse AuthorDate:Sat, 24 Oct 2020 22:35:29 +01:00

Re: [PATCH v2 1/2] sched/wait: Add add_wait_queue_priority()

2020-10-27 Thread David Woodhouse
On Tue, 2020-10-27 at 21:30 +0100, Peter Zijlstra wrote: > On Tue, Oct 27, 2020 at 07:27:59PM +0000, David Woodhouse wrote: > > > > While looking at this I found that weird __add_wait_queue_exclusive() > > > which is used by fs/eventpoll.c and does something similar, exce

Re: [PATCH v2 1/2] sched/wait: Add add_wait_queue_priority()

2020-10-27 Thread David Woodhouse
On Tue, 2020-10-27 at 21:30 +0100, Peter Zijlstra wrote: > On Tue, Oct 27, 2020 at 07:27:59PM +0000, David Woodhouse wrote: > > > > While looking at this I found that weird __add_wait_queue_exclusive() > > > which is used by fs/eventpoll.c and does something similar, exce

Re: [PATCH v2 1/2] sched/wait: Add add_wait_queue_priority()

2020-10-27 Thread David Woodhouse
On Tue, 2020-10-27 at 20:09 +0100, Peter Zijlstra wrote: > On Tue, Oct 27, 2020 at 02:39:43PM +0000, David Woodhouse wrote: > > From: David Woodhouse > > > > This allows an exclusive wait_queue_entry to be added at the head of the > > queue, instead of the ta

[PATCH v2 1/2] sched/wait: Add add_wait_queue_priority()

2020-10-27 Thread David Woodhouse
From: David Woodhouse This allows an exclusive wait_queue_entry to be added at the head of the queue, instead of the tail as normal. Thus, it gets to consume events first without allowing non-exclusive waiters to be woken at all. The (first) intended use is for KVM IRQFD, which currently has

[PATCH v2 2/2] kvm/eventfd: Use priority waitqueue to catch events before userspace

2020-10-27 Thread David Woodhouse
From: David Woodhouse When posted interrupts are available, the IRTE is modified to deliver interrupts direclty to the vCPU and nothing ever reaches userspace, if it's listening on the same eventfd that feeds the irqfd. I like that behaviour. Let's do it all the time, even without posted

[PATCH v2 0/2] Allow KVM IRQFD to consistently intercept events

2020-10-27 Thread David Woodhouse
consume the eventfd counter too. David Woodhouse (2): sched/wait: Add add_wait_queue_priority() kvm/eventfd: Use priority waitqueue to catch events before userspace include/linux/wait.h | 12 +++- kernel/sched/wait.c | 17 - virt/kvm/eventfd.c | 6 --

[PATCH 0/3] Allow in-kernel consumers to drain events from eventfd

2020-10-27 Thread David Woodhouse
it as they handle their respective events. David Woodhouse (3): eventfd: Export eventfd_ctx_do_read() vfio/virqfd: Drain events from eventfd in virqfd_wakeup() kvm/eventfd: Drain events from eventfd in irqfd_wakeup() drivers/vfio/virqfd.c | 3 +++ fs/eventfd.c| 5 - include

[PATCH 2/3] vfio/virqfd: Drain events from eventfd in virqfd_wakeup()

2020-10-27 Thread David Woodhouse
From: David Woodhouse Don't allow the events to accumulate in the eventfd counter, drain them as they are handled. Signed-off-by: David Woodhouse --- drivers/vfio/virqfd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/vfio/virqfd.c b/drivers/vfio/virqfd.c index 997cb5d0a657

[PATCH 1/3] eventfd: Export eventfd_ctx_do_read()

2020-10-27 Thread David Woodhouse
From: David Woodhouse Where events are consumed in the kernel, for example by KVM's irqfd_wakeup() and VFIO's virqfd_wakeup(), they currently lack a mechanism to drain the eventfd's counter. Since the wait queue is already locked while the wakeup functions are invoked, all they really need

[PATCH 3/3] kvm/eventfd: Drain events from eventfd in irqfd_wakeup()

2020-10-27 Thread David Woodhouse
From: David Woodhouse Don't allow the events to accumulate in the eventfd counter, drain them as they are handled. Signed-off-by: David Woodhouse --- virt/kvm/eventfd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c index d6408bb497dc

Re: [RFC PATCH 2/2] kvm/eventfd: Use priority waitqueue to catch events before userspace

2020-10-27 Thread David Woodhouse
On Tue, 2020-10-27 at 09:01 +0100, Paolo Bonzini wrote: > On 26/10/20 18:53, David Woodhouse wrote: > > From: David Woodhouse > > > > As far as I can tell, when we use posted interrupts we silently cut off > > the events from userspace, if it's listening on the

[RFC PATCH 2/2] kvm/eventfd: Use priority waitqueue to catch events before userspace

2020-10-26 Thread David Woodhouse
From: David Woodhouse As far as I can tell, when we use posted interrupts we silently cut off the events from userspace, if it's listening on the same eventfd that feeds the irqfd. I like that behaviour. Let's do it all the time, even without posted interrupts. It makes it much easier to handle

  1   2   3   4   5   6   7   8   9   10   >