From ed6069be7204541c1da532ad8bbf892e34513552 Mon Sep 17 00:00:00 2001 From: Boris Ostrovsky Date: Thu, 17 Mar 2016 09:03:24 -0400 Subject: [PATCH 1/5] xen/apic: Provide Xen-specific version of cpu_present_to_apicid APIC op Currently Xen uses default_cpu_present_to_apicid() which will always report BAD_APICID for PV guests since x86_bios_cpu_apic_id is initialised to that value and is never updated. With commit 1f12e32f4cd5 ("x86/topology: Create logical package id"), this op is now called by smp_init_package_map() when deciding whether to call topology_update_package_map() which sets cpu_data(cpu).logical_proc_id. The latter (as topology_logical_package_id(cpu)) may be used, for example, by cpu_to_rapl_pmu() as an array index. Since uninitialized logical_package_id is set to -1, the index will become 64K which is obviously problematic. While RAPL code (and any other users of logical_package_id) should be careful in their assumptions about id's validity, Xen's cpu_present_to_apicid op should still provide value consistent with its own xen_apic_read(APIC_ID). Signed-off-by: Boris Ostrovsky Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/apic.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c index abf4901c917b..db52a7fafcc2 100644 --- a/arch/x86/xen/apic.c +++ b/arch/x86/xen/apic.c @@ -66,7 +66,7 @@ static u32 xen_apic_read(u32 reg) ret = HYPERVISOR_platform_op(&op); if (ret) - return 0; + op.u.pcpu_info.apic_id = BAD_APICID; return op.u.pcpu_info.apic_id << 24; } @@ -142,6 +142,14 @@ static void xen_silent_inquire(int apicid) { } +static int xen_cpu_present_to_apicid(int cpu) +{ + if (cpu_present(cpu)) + return xen_get_apic_id(xen_apic_read(APIC_ID)); + else + return BAD_APICID; +} + static struct apic xen_pv_apic = { .name = "Xen PV", .probe = xen_apic_probe_pv, @@ -162,7 +170,7 @@ static struct apic xen_pv_apic = { .ioapic_phys_id_map = default_ioapic_phys_id_map, /* Used on 32-bit */ .setup_apic_routing = NULL, - .cpu_present_to_apicid = default_cpu_present_to_apicid, + .cpu_present_to_apicid = xen_cpu_present_to_apicid, .apicid_to_cpu_present = physid_set_mask_of_physid, /* Used on 32-bit */ .check_phys_apicid_present = default_check_phys_apicid_present, /* smp_sanity_check needs it */ .phys_pkg_id = xen_phys_pkg_id, /* detect_ht */ From dc6416f1d711eb4c1726e845d653235dcaae12e1 Mon Sep 17 00:00:00 2001 From: Boris Ostrovsky Date: Thu, 17 Mar 2016 09:03:25 -0400 Subject: [PATCH 2/5] xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead() This call has always been missing from xen_play dead() but until recently this was rather benign. With new cpu hotplug framework (commit 8df3e07e7f21 ("cpu/hotplug: Let upcoming cpu bring itself fully up"). however this call is required, otherwise a hot-plugged CPU will not be properly brough up (by never calling cpuhp_online_idle()) Signed-off-by: Boris Ostrovsky Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/xen/smp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c index 3c6d17fd423a..719cf291dcdf 100644 --- a/arch/x86/xen/smp.c +++ b/arch/x86/xen/smp.c @@ -545,6 +545,8 @@ static void xen_play_dead(void) /* used only with HOTPLUG_CPU */ * data back is to call: */ tick_nohz_idle_enter(); + + cpu_startup_entry(CPUHP_AP_ONLINE_IDLE); } #else /* !CONFIG_HOTPLUG_CPU */ From 85d1a29de8e4e5bce20ca02103acf1082a6e530a Mon Sep 17 00:00:00 2001 From: Stefano Stabellini Date: Tue, 29 Mar 2016 11:01:16 +0100 Subject: [PATCH 3/5] Xen on ARM and ARM64: update MAINTAINERS info Not my full time job anymore, but still maintaining it. Signed-off-by: Stefano Stabellini Signed-off-by: Konrad Rzeszutek Wilk --- MAINTAINERS | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 03e00c7c88eb..52b8c2c1ac01 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12216,16 +12216,16 @@ F: include/xen/ F: include/uapi/xen/ XEN HYPERVISOR ARM -M: Stefano Stabellini +M: Stefano Stabellini L: xen-devel@lists.xenproject.org (moderated for non-subscribers) -S: Supported +S: Maintained F: arch/arm/xen/ F: arch/arm/include/asm/xen/ XEN HYPERVISOR ARM64 -M: Stefano Stabellini +M: Stefano Stabellini L: xen-devel@lists.xenproject.org (moderated for non-subscribers) -S: Supported +S: Maintained F: arch/arm64/xen/ F: arch/arm64/include/asm/xen/ From ff1e22e7a638a0782f54f81a6c9cb139aca2da35 Mon Sep 17 00:00:00 2001 From: Boris Ostrovsky Date: Fri, 18 Mar 2016 10:11:07 -0400 Subject: [PATCH 4/5] xen/events: Mask a moving irq Moving an unmasked irq may result in irq handler being invoked on both source and target CPUs. With 2-level this can happen as follows: On source CPU: evtchn_2l_handle_events() -> generic_handle_irq() -> handle_edge_irq() -> eoi_pirq(): irq_move_irq(data); /***** WE ARE HERE *****/ if (VALID_EVTCHN(evtchn)) clear_evtchn(evtchn); If at this moment target processor is handling an unrelated event in evtchn_2l_handle_events()'s loop it may pick up our event since target's cpu_evtchn_mask claims that this event belongs to it *and* the event is unmasked and still pending. At the same time, source CPU will continue executing its own handle_edge_irq(). With FIFO interrupt the scenario is similar: irq_move_irq() may result in a EVTCHNOP_unmask hypercall which, in turn, may make the event pending on the target CPU. We can avoid this situation by moving and clearing the event while keeping event masked. Signed-off-by: Boris Ostrovsky Cc: stable@vger.kernel.org Signed-off-by: David Vrabel --- drivers/xen/events/events_base.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c index 488017a0806a..cb7138c97c69 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -484,9 +484,19 @@ static void eoi_pirq(struct irq_data *data) struct physdev_eoi eoi = { .irq = pirq_from_irq(data->irq) }; int rc = 0; - irq_move_irq(data); + if (!VALID_EVTCHN(evtchn)) + return; - if (VALID_EVTCHN(evtchn)) + if (unlikely(irqd_is_setaffinity_pending(data))) { + int masked = test_and_set_mask(evtchn); + + clear_evtchn(evtchn); + + irq_move_masked_irq(data); + + if (!masked) + unmask_evtchn(evtchn); + } else clear_evtchn(evtchn); if (pirq_needs_eoi(data->irq)) { @@ -1357,9 +1367,19 @@ static void ack_dynirq(struct irq_data *data) { int evtchn = evtchn_from_irq(data->irq); - irq_move_irq(data); + if (!VALID_EVTCHN(evtchn)) + return; - if (VALID_EVTCHN(evtchn)) + if (unlikely(irqd_is_setaffinity_pending(data))) { + int masked = test_and_set_mask(evtchn); + + clear_evtchn(evtchn); + + irq_move_masked_irq(data); + + if (!masked) + unmask_evtchn(evtchn); + } else clear_evtchn(evtchn); } From 101ecde566963b8d95d2b1b5ce0d4f3ed2f75933 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk Date: Fri, 1 Apr 2016 11:26:08 -0400 Subject: [PATCH 5/5] MAINTAINERS: xen: Konrad to step down and Juergen to pick up I've lately been concentrating on other projects and haven't been doing much of Xen core maintainership for the last year. I am quite thrilled that Juergen is willing to help out! P.S. I am still the maintainer of Xen-SWIOTLB, Xen PCI-[front|backend], and co-maintainer of Xen block-[front|backend]; amongst others. Acked-by: Juergen Gross Acked-by: Boris Ostrovsky Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: David Vrabel --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 52b8c2c1ac01..fa6ccf7096a3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12202,9 +12202,9 @@ S: Maintained F: drivers/media/tuners/tuner-xc2028.* XEN HYPERVISOR INTERFACE -M: Konrad Rzeszutek Wilk M: Boris Ostrovsky M: David Vrabel +M: Juergen Gross L: xen-devel@lists.xenproject.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git S: Supported