From: David Vrabel <david.vrabel@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>, <xen-devel@lists.xenproject.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Andrew Jones <drjones@redhat.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC 3/4] xen/pvhvm: Unmap all PIRQs on startup and shutdown
Date: Mon, 28 Jul 2014 14:43:10 +0100 [thread overview]
Message-ID: <53D6536E.70104@citrix.com> (raw)
In-Reply-To: <1405431640-649-4-git-send-email-vkuznets@redhat.com>
On 15/07/14 14:40, Vitaly Kuznetsov wrote:
> When kexec is being run PIRQs from Qemu-emulated devices are still
> mapped to old event channels and new kernel has no information about
> that. Trying to map them twice results in the following in Xen's dmesg:
>
> (XEN) irq.c:2278: dom7: pirq 24 or emuirq 8 already mapped
> (XEN) irq.c:2278: dom7: pirq 24 or emuirq 12 already mapped
> (XEN) irq.c:2278: dom7: pirq 24 or emuirq 1 already mapped
> ...
>
> and the following in new kernel's dmesg:
>
> [ 92.286796] xen:events: Failed to obtain physical IRQ 4
>
> The result is that the new kernel doesn't recieve IRQs for Qemu-emulated
> devices. Address the issue by unmapping all mapped PIRQs on kernel shutdown
> when kexec was requested and on every kernel startup. We need to do this
> twice to deal with the following issues:
> - startup-time unmapping is required to make kdump work;
> - shutdown-time unmapping is required to support kexec-ing non-fixed kernels;
> - shutdown-time unmapping is required to make Qemu-emulated NICs work after
> kexec (event channel is being closed on shutdown but no PHYSDEVOP_unmap_pirq
> is being performed).
I think this should be done only in one place -- just prior to exec'ing
the new kernel (including kdump kernels).
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -768,6 +768,7 @@ void xen_kexec_shutdown(void)
> #ifdef CONFIG_KEXEC
> if (!kexec_in_progress)
> return;
> + xen_unmap_all_pirqs();
> #endif
> }
>
> diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
> index c919d3d..7701c7f 100644
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -1643,6 +1643,80 @@ void xen_callback_vector(void) {}
> static bool fifo_events = true;
> module_param(fifo_events, bool, 0);
>
> +void xen_unmap_all_pirqs(void)
> +{
> + int pirq, rc, gsi, irq, evtchn;
> + struct physdev_unmap_pirq unmap_irq;
> + struct irq_info *info;
> + struct evtchn_close close;
> +
> + mutex_lock(&irq_mapping_update_lock);
> +
> + list_for_each_entry(info, &xen_irq_list_head, list) {
> + if (info->type != IRQT_PIRQ)
> + continue;
I think you need to do this by querying Xen state rather than relying on
potentially bad guest state. Particularly since you may crash while
holding irq_mapping_update_lock.
EVTCHNOP_status gets you the info you need I think.
David
next prev parent reply other threads:[~2014-07-28 13:43 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 13:40 [PATCH RFC 0/4] xen/pvhvm: fix shared_info and pirq issues with kexec Vitaly Kuznetsov
2014-07-15 13:40 ` [PATCH RFC 1/4] xen PVonHVM: use E820_Reserved area for shared_info Vitaly Kuznetsov
2014-07-15 13:40 ` Vitaly Kuznetsov
2014-07-15 15:06 ` Konrad Rzeszutek Wilk
2014-07-15 15:43 ` Vitaly Kuznetsov
2014-07-15 15:50 ` Konrad Rzeszutek Wilk
2014-07-18 11:05 ` Vitaly Kuznetsov
2014-07-18 11:05 ` Vitaly Kuznetsov
2014-07-18 13:56 ` Konrad Rzeszutek Wilk
2014-07-18 13:56 ` Konrad Rzeszutek Wilk
2014-07-18 15:45 ` Vitaly Kuznetsov
2014-07-18 15:45 ` Vitaly Kuznetsov
2014-07-15 15:50 ` Konrad Rzeszutek Wilk
2014-07-15 15:43 ` Vitaly Kuznetsov
2014-07-15 15:06 ` Konrad Rzeszutek Wilk
2014-07-28 13:33 ` David Vrabel
2014-08-04 15:15 ` Konrad Rzeszutek Wilk
2014-08-04 15:15 ` Konrad Rzeszutek Wilk
2014-07-28 13:33 ` David Vrabel
2014-07-15 13:40 ` [PATCH RFC 2/4] xen/pvhvm: Introduce xen_pvhvm_kexec_shutdown() Vitaly Kuznetsov
2014-07-15 13:40 ` Vitaly Kuznetsov
2014-07-15 15:09 ` Konrad Rzeszutek Wilk
2014-07-15 15:09 ` Konrad Rzeszutek Wilk
2014-07-15 15:52 ` Vitaly Kuznetsov
2014-07-15 15:58 ` Konrad Rzeszutek Wilk
2014-07-15 15:58 ` Konrad Rzeszutek Wilk
2014-07-15 15:52 ` Vitaly Kuznetsov
2014-07-15 17:41 ` Boris Ostrovsky
2014-07-15 17:41 ` Boris Ostrovsky
2014-07-28 13:36 ` David Vrabel
2014-07-28 13:36 ` David Vrabel
2014-07-15 13:40 ` [PATCH RFC 3/4] xen/pvhvm: Unmap all PIRQs on startup and shutdown Vitaly Kuznetsov
2014-07-15 13:40 ` Vitaly Kuznetsov
2014-07-15 15:23 ` Konrad Rzeszutek Wilk
2014-07-15 15:23 ` Konrad Rzeszutek Wilk
2014-07-16 9:37 ` Vitaly Kuznetsov
2014-07-16 13:45 ` Konrad Rzeszutek Wilk
2014-07-16 16:34 ` Vitaly Kuznetsov
2014-07-16 16:34 ` Vitaly Kuznetsov
2014-07-16 13:45 ` Konrad Rzeszutek Wilk
2014-07-16 9:37 ` Vitaly Kuznetsov
2014-07-28 13:43 ` David Vrabel [this message]
2014-07-29 13:50 ` Vitaly Kuznetsov
2014-07-29 15:25 ` [Xen-devel] " David Vrabel
2014-07-29 17:06 ` Vitaly Kuznetsov
2014-07-29 17:12 ` David Vrabel
2014-07-29 17:12 ` David Vrabel
2014-07-29 17:06 ` Vitaly Kuznetsov
2014-07-29 15:25 ` David Vrabel
2014-07-29 13:50 ` Vitaly Kuznetsov
2014-07-28 13:43 ` David Vrabel
2014-07-15 13:40 ` [PATCH RFC 4/4] xen/pvhvm: Make MSI IRQs work after kexec Vitaly Kuznetsov
2014-07-15 13:40 ` Vitaly Kuznetsov
2014-07-15 15:21 ` Konrad Rzeszutek Wilk
2014-07-16 9:01 ` Vitaly Kuznetsov
2014-07-16 13:40 ` Konrad Rzeszutek Wilk
2014-07-16 13:40 ` Konrad Rzeszutek Wilk
2014-07-16 17:20 ` Vitaly Kuznetsov
2014-07-16 17:20 ` Vitaly Kuznetsov
2014-07-16 17:30 ` Konrad Rzeszutek Wilk
2014-07-16 17:30 ` Konrad Rzeszutek Wilk
2014-07-17 8:12 ` Vitaly Kuznetsov
2014-07-17 8:12 ` Vitaly Kuznetsov
2014-07-28 13:47 ` David Vrabel
2014-07-28 13:47 ` David Vrabel
2014-07-21 14:13 ` Stefano Stabellini
2014-07-21 14:13 ` Stefano Stabellini
2014-07-16 9:01 ` Vitaly Kuznetsov
2014-07-15 15:21 ` Konrad Rzeszutek Wilk
2014-07-28 13:24 ` [PATCH RFC 0/4] xen/pvhvm: fix shared_info and pirq issues with kexec David Vrabel
2014-07-28 13:24 ` David Vrabel
2014-08-01 12:21 ` Vitaly Kuznetsov
2014-08-01 12:21 ` Vitaly Kuznetsov
2014-08-01 13:00 ` David Vrabel
2014-08-01 13:00 ` David Vrabel
2014-08-04 15:44 ` Vitaly Kuznetsov
2014-08-04 15:44 ` Vitaly Kuznetsov
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=53D6536E.70104@citrix.com \
--to=david.vrabel@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=drjones@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=vkuznets@redhat.com \
--cc=xen-devel@lists.xenproject.org \
/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: link
Be 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.