From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: david.vrabel@citrix.com, ian.campbell@citrix.com,
jbeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [PATCH 10/13] xen: introduce xen_event_channel_register_3level
Date: Tue, 5 Feb 2013 11:55:52 -0500 [thread overview]
Message-ID: <20130205165550.GC2187@konrad-lan.dumpdata.com> (raw)
In-Reply-To: <1359643627-29486-11-git-send-email-wei.liu2@citrix.com>
On Thu, Jan 31, 2013 at 02:47:04PM +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
> drivers/xen/events.c | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 94 insertions(+)
>
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index d953e81..9038211 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -53,6 +53,9 @@
>
> /* Helper macro(s) */
> #define LONG_BITORDER (BITS_PER_LONG == 64 ? 6 : 5)
Can you provide a comment explaining why the '6' or '5' value?
> +/* event bitmap size: 1 page for 32 bit and 8 pages for 64 bit */
> +#define BITMAP_PG_ORDER (BITS_PER_LONG == 64 ? 3 : 1)
> +#define BITMAP_NR_PAGES (BITMAP_PG_ORDER == 3 ? 8 : 1)
Is there some math behind this? Could you provide a comment explaining
the reason for needing so much for a 64-bit vs only needing on page on
32-bit?
>
> /* N-level event channel, starting from 2 */
> unsigned int evtchn_level = 2;
> @@ -2123,6 +2126,97 @@ void xen_callback_vector(void)
> void xen_callback_vector(void) {}
> #endif
>
> +static int xen_event_channel_register_3level(void)
> +{
> + evtchn_register_nlevel_t reg;
Please no typdefs.
> + int i, cpu;
> + unsigned long *_evtchn_pending = NULL;
> + unsigned long *_evtchn_mask = NULL;
> + unsigned long *l2sel_mfns = NULL;
> + unsigned long *l2sel_offsets = NULL;
> + int rc;
> +
> + /* If we come from restore path, we don't need to allocate
> + * pages.
> + */
> + if (!evtchn_pending && !evtchn_mask) {
> + evtchn_pending =
> + (unsigned long *)__get_free_pages(GFP_KERNEL,
> + BITMAP_PG_ORDER);
> + evtchn_mask =
> + (unsigned long *)__get_free_pages(GFP_KERNEL,
> + BITMAP_PG_ORDER);
> + if (!evtchn_pending || !evtchn_mask) {
> + free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> + free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> + evtchn_pending = NULL;
> + evtchn_mask = NULL;
> + rc = -ENOMEM;
> + goto err;
> + }
> + }
> +
> + rc = -ENOMEM; /* Common error code for following operations */
> +#define __ALLOC_ARRAY(_ptr, _nr) \
> + do { \
> + (_ptr) = kzalloc(sizeof(unsigned long) * (_nr), \
> + GFP_KERNEL); \
> + if (!(_ptr)) \
> + goto out; \
> + } while (0)
> +
> + __ALLOC_ARRAY(_evtchn_pending, BITMAP_NR_PAGES);
> + __ALLOC_ARRAY(_evtchn_mask, BITMAP_NR_PAGES);
> + __ALLOC_ARRAY(l2sel_mfns, nr_cpu_ids);
> + __ALLOC_ARRAY(l2sel_offsets, nr_cpu_ids);
> +#undef __ALLOC_ARRAY
> +
> + memset(®, 0, sizeof(reg));
> +
> + for (i = 0; i < BITMAP_NR_PAGES; i++) {
> + unsigned long offset = PAGE_SIZE * i;
> + _evtchn_pending[i] =
> + arbitrary_virt_to_mfn(
> + (void *)((unsigned long)evtchn_pending+offset));
> + _evtchn_mask[i] =
> + arbitrary_virt_to_mfn(
> + (void *)((unsigned long)evtchn_mask+offset));
> + }
> +
> + for_each_possible_cpu(cpu) {
> + l2sel_mfns[cpu] =
> + arbitrary_virt_to_mfn(&per_cpu(evtchn_sel_l2, cpu));
> + l2sel_offsets[cpu] =
> + offset_in_page(&per_cpu(evtchn_sel_l2, cpu));
> + }
> +
> + reg.u.l3.nr_pages = BITMAP_NR_PAGES;
> + reg.u.l3.evtchn_pending = _evtchn_pending;
> + reg.u.l3.evtchn_mask = _evtchn_mask;
> +
> + reg.u.l3.nr_vcpus = nr_cpu_ids;
> + reg.u.l3.l2sel_mfns = l2sel_mfns;
> + reg.u.l3.l2sel_offsets = l2sel_offsets;
> +
> + reg.level = 3;
> +
> + rc = HYPERVISOR_event_channel_op(EVTCHNOP_register_nlevel, ®);
> + if (rc) {
> + free_pages((unsigned long)evtchn_pending, BITMAP_NR_PAGES);
> + free_pages((unsigned long)evtchn_mask, BITMAP_NR_PAGES);
> + evtchn_pending = NULL;
> + evtchn_mask = NULL;
> + }
> +
> +out:
> + kfree(_evtchn_pending);
> + kfree(_evtchn_mask);
> + kfree(l2sel_mfns);
> + kfree(l2sel_offsets);
So it is OK to just free it even on success??
> +err:
> + return rc;
> +}
> +
> void __init xen_init_IRQ(void)
> {
> int i, rc;
> --
> 1.7.10.4
>
next prev parent reply other threads:[~2013-02-05 16:55 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-31 14:46 [PATCH 00/13] Implement 3-level event channel in Linux Wei Liu
2013-01-31 14:46 ` [PATCH 01/13] xen: fix output of xen_debug_interrupt Wei Liu
2013-02-01 11:06 ` David Vrabel
2013-02-01 13:10 ` Wei Liu
2013-02-01 13:14 ` Wei Liu
2013-01-31 14:46 ` [PATCH 02/13] xen: fix error handling path if xen_allocate_irq_dynamic fails Wei Liu
2013-02-01 11:19 ` David Vrabel
2013-02-01 11:26 ` Ian Campbell
2013-02-01 12:36 ` Wei Liu
2013-02-06 15:49 ` Konrad Rzeszutek Wilk
2013-01-31 14:46 ` [PATCH 03/13] xen: fix evtchn_unbind_from_user Wei Liu
2013-02-01 11:15 ` David Vrabel
2013-02-01 12:33 ` Wei Liu
2013-02-05 16:57 ` Konrad Rzeszutek Wilk
2013-01-31 14:46 ` [PATCH 04/13] xen: sync public headers Wei Liu
2013-02-05 17:00 ` Konrad Rzeszutek Wilk
2013-02-05 17:23 ` Wei Liu
2013-02-06 16:57 ` Konrad Rzeszutek Wilk
2013-02-07 9:22 ` Paul Durrant
2013-02-07 11:57 ` Wei Liu
2013-02-08 16:06 ` Paul Durrant
2013-02-08 16:22 ` Ian Campbell
2013-02-08 16:36 ` Paul Durrant
2013-02-08 16:49 ` Tim Deegan
2013-02-08 16:56 ` Jan Beulich
2013-02-08 16:59 ` Ian Campbell
2013-02-08 17:06 ` Tim Deegan
2013-02-08 17:09 ` Ian Campbell
2013-02-08 19:45 ` David Vrabel
2013-02-08 19:55 ` Ian Campbell
2013-02-08 17:07 ` Paul Durrant
2013-02-08 16:37 ` Wei Liu
2013-02-08 16:40 ` Ian Campbell
2013-02-07 12:23 ` Ian Campbell
2013-01-31 14:46 ` [PATCH 05/13] xen: introduce test_and_set_mask Wei Liu
2013-02-01 11:35 ` David Vrabel
2013-02-01 22:08 ` Ian Campbell
2013-01-31 14:47 ` [PATCH 06/13] xen: replace raw bit ops with functions Wei Liu
2013-01-31 14:47 ` [PATCH 07/13] xen: generalized event channel operations Wei Liu
2013-02-05 17:04 ` Konrad Rzeszutek Wilk
2013-02-05 17:08 ` Wei Liu
2013-02-05 17:19 ` Konrad Rzeszutek Wilk
2013-02-05 17:23 ` Wei Liu
2013-02-05 19:44 ` Konrad Rzeszutek Wilk
2013-01-31 14:47 ` [PATCH 08/13] xen: dynamically allocate cpu_evtchn_mask Wei Liu
2013-02-01 11:29 ` David Vrabel
2013-01-31 14:47 ` [PATCH 09/13] xen: implement 3-level event channel routines Wei Liu
2013-02-05 17:09 ` Konrad Rzeszutek Wilk
2013-02-05 17:39 ` Wei Liu
2013-02-05 19:46 ` Konrad Rzeszutek Wilk
2013-01-31 14:47 ` [PATCH 10/13] xen: introduce xen_event_channel_register_3level Wei Liu
2013-02-04 8:56 ` Jan Beulich
2013-02-04 10:36 ` Wei Liu
2013-02-05 16:55 ` Konrad Rzeszutek Wilk [this message]
2013-02-05 17:05 ` Wei Liu
2013-02-05 17:14 ` Konrad Rzeszutek Wilk
2013-01-31 14:47 ` [PATCH 11/13] xen: introduce xen_event_channel_register_nlevel Wei Liu
2013-01-31 14:47 ` [PATCH 12/13] xen: register 3-level event channel Wei Liu
2013-02-01 11:31 ` David Vrabel
2013-01-31 14:47 ` [PATCH 13/13] xen: only register 3-level event channel for Dom0 Wei Liu
2013-01-31 16:39 ` Wei Liu
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=20130205165550.GC2187@konrad-lan.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=jbeulich@suse.com \
--cc=wei.liu2@citrix.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 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.