xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH 02/13] xen/events: remove unnecessary init_evtchn_cpu_bindings()
Date: Tue, 24 Sep 2013 10:40:04 -0400	[thread overview]
Message-ID: <20130924144004.GC4712@phenom.dumpdata.com> (raw)
In-Reply-To: <1379091601-30358-3-git-send-email-david.vrabel@citrix.com>

On Fri, Sep 13, 2013 at 05:59:50PM +0100, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Event channels are always explicitly bound to a specific VCPU before
> they are first enabled.  There is no need to initialize all possible
> events as bound to VCPU 0 at start of day or after a resume.

How long has this presumption about explicit bounding been in the
hypervisor?

Should there also be a patch in the Xen headers documenting this
behavior?

Looks good to me - thought I would add the comment mentioning how
long this behavior has been with the hypervisor - as we still can
run on Xen 4.0 hypervisors and should not break that (and perhaps
they don't rebind there?).

> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  drivers/xen/events.c |   22 ----------------------
>  1 files changed, 0 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index ddcdbb5..1e2c74b 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -334,24 +334,6 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
>  	info_for_irq(irq)->cpu = cpu;
>  }
>  
> -static void init_evtchn_cpu_bindings(void)
> -{
> -	int i;
> -#ifdef CONFIG_SMP
> -	struct irq_info *info;
> -
> -	/* By default all event channels notify CPU#0. */
> -	list_for_each_entry(info, &xen_irq_list_head, list) {
> -		struct irq_desc *desc = irq_to_desc(info->irq);
> -		cpumask_copy(desc->irq_data.affinity, cpumask_of(0));
> -	}
> -#endif
> -
> -	for_each_possible_cpu(i)
> -		memset(per_cpu(cpu_evtchn_mask, i),
> -		       (i == 0) ? ~0 : 0, NR_EVENT_CHANNELS/8);
> -}
> -
>  static inline void clear_evtchn(int port)
>  {
>  	struct shared_info *s = HYPERVISOR_shared_info;
> @@ -1778,8 +1760,6 @@ void xen_irq_resume(void)
>  	unsigned int cpu, evtchn;
>  	struct irq_info *info;
>  
> -	init_evtchn_cpu_bindings();
> -
>  	/* New event-channel space is not 'live' yet. */
>  	for (evtchn = 0; evtchn < NR_EVENT_CHANNELS; evtchn++)
>  		mask_evtchn(evtchn);
> @@ -1890,8 +1870,6 @@ void __init xen_init_IRQ(void)
>  	for (i = 0; i < NR_EVENT_CHANNELS; i++)
>  		evtchn_to_irq[i] = -1;
>  
> -	init_evtchn_cpu_bindings();
> -
>  	/* No event channels are 'live' right now. */
>  	for (i = 0; i < NR_EVENT_CHANNELS; i++)
>  		mask_evtchn(i);
> -- 
> 1.7.2.5
> 

  reply	other threads:[~2013-09-24 14:40 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-13 16:59 (no subject) David Vrabel
2013-09-13 16:59 ` [PATCH 01/13] xen/events: refactor retrigger_dynirq() and resend_irq_on_evtchn() David Vrabel
2013-09-24 14:37   ` Konrad Rzeszutek Wilk
2013-09-24 16:04     ` David Vrabel
2013-09-13 16:59 ` [PATCH 02/13] xen/events: remove unnecessary init_evtchn_cpu_bindings() David Vrabel
2013-09-24 14:40   ` Konrad Rzeszutek Wilk [this message]
2013-09-24 16:06     ` David Vrabel
2013-09-24 16:49       ` Konrad Rzeszutek Wilk
2013-09-13 16:59 ` [PATCH 03/13] xen/events: introduce test_and_set_mask David Vrabel
2013-09-24 14:40   ` Konrad Rzeszutek Wilk
2013-09-13 16:59 ` [PATCH 04/13] xen/events: replace raw bit ops with functions David Vrabel
2013-09-24 14:41   ` Konrad Rzeszutek Wilk
2013-09-13 16:59 ` [PATCH 05/13] xen/events: move drivers/xen/events.c into drivers/xen/events/ David Vrabel
2013-09-13 16:59 ` [PATCH 06/13] xen/events: move 2-level specific code into its own file David Vrabel
2013-09-13 16:59 ` [PATCH 07/13] xen/events: add struct evtchn_ops for the low-level port operations David Vrabel
2013-09-24 14:44   ` Konrad Rzeszutek Wilk
2013-09-13 16:59 ` [PATCH 08/13] xen/events: allow setup of irq_info to fail David Vrabel
2013-09-24 14:47   ` Konrad Rzeszutek Wilk
2013-09-13 16:59 ` [PATCH 09/13] xen/events: add a evtchn_op for port setup David Vrabel
2013-09-24 14:47   ` Konrad Rzeszutek Wilk
2013-09-13 16:59 ` [PATCH 10/13] xen/events: Refactor evtchn_to_irq array to be dynamically allocated David Vrabel
2013-09-24 14:58   ` Konrad Rzeszutek Wilk
2013-09-26 10:53     ` David Vrabel
2013-09-26 12:51       ` Konrad Rzeszutek Wilk
2013-09-13 16:59 ` [PATCH 11/13] xen/events: add xen_evtchn_mask_all() David Vrabel
2013-09-24 14:58   ` Konrad Rzeszutek Wilk
2013-09-13 17:00 ` [PATCH 12/13] xen/events: Add the hypervisor interface for the FIFO-based event channels David Vrabel
2013-09-24 15:06   ` Konrad Rzeszutek Wilk
2013-09-26 11:06     ` David Vrabel
2013-09-24 15:08   ` Konrad Rzeszutek Wilk
2013-09-24 16:11     ` David Vrabel
2013-09-24 16:51       ` Konrad Rzeszutek Wilk
2013-09-13 17:00 ` [PATCH 13/13] xen/events: use the FIFO-based ABI if available David Vrabel
2013-09-24 15:50   ` Konrad Rzeszutek Wilk
2013-09-24 16:48     ` David Vrabel
2013-09-24 17:04       ` Konrad Rzeszutek Wilk
2013-09-13 17:03 ` [RFC PATCHv3 00/12] Linux: FIFO-based event channel ABI David Vrabel

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=20130924144004.GC4712@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=xen-devel@lists.xen.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;
as well as URLs for NNTP newsgroup(s).