public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2014-07-28 13:43 UTC|newest]

Thread overview: 39+ 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 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 13:56           ` Konrad Rzeszutek Wilk
2014-07-18 15:45             ` Vitaly Kuznetsov
2014-07-28 13:33   ` David Vrabel
2014-08-04 15:15     ` Konrad Rzeszutek Wilk
2014-07-15 13:40 ` [PATCH RFC 2/4] xen/pvhvm: Introduce xen_pvhvm_kexec_shutdown() Vitaly Kuznetsov
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 17:41   ` Boris Ostrovsky
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 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-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-15 13:40 ` [PATCH RFC 4/4] xen/pvhvm: Make MSI IRQs work after kexec 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 17:20         ` Vitaly Kuznetsov
2014-07-16 17:30           ` Konrad Rzeszutek Wilk
2014-07-17  8:12             ` Vitaly Kuznetsov
2014-07-28 13:47           ` David Vrabel
2014-07-21 14:13         ` Stefano Stabellini
2014-07-28 13:24 ` [PATCH RFC 0/4] xen/pvhvm: fix shared_info and pirq issues with kexec David Vrabel
2014-08-01 12:21   ` Vitaly Kuznetsov
2014-08-01 13:00     ` David Vrabel
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox