All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Re: non-contiguous allocations
Date: Mon, 09 May 2011 15:14:10 +0100	[thread overview]
Message-ID: <C9EDB542.18CDF%keir.xen@gmail.com> (raw)
In-Reply-To: <20110509124314.GA19179@aepfle.de>

On 09/05/2011 13:43, "Olaf Hering" <olaf@aepfle.de> wrote:

>> Yes, sticking with alloc_xenheap_pages() is good.
> 
> Another question:
> alloc_trace_bufs() calls alloc_xenheap_pages(0, MEMF_bits(32 + PAGE_SHIFT));
> 
> MEMF_bits() is not used in the i386 codepath in alloc_heap_pages(),
> unless I miss something.

On i386 the xenheap is drawn from the bottom 12MB of physical memory, hence
restricting address width doesn't need to be explicitly handled -- no caller
requires addresses below 8MB.

> Otherwise alloc_domheap_pages() is called, which passes BITS_PER_LONG
> instead of 32 to domain_clamp_alloc_bitsize().
>
> Is the hardcoded 32+PAGE_SHIFT required in some way,

The allocated MFNs get passed to dom0 userspace in a uint32_t array. Hence
MFNs cannot be wider than 32 bits. Hence physical addresses of trace pages
cannot be wider than 32+PAGE_SHIFT bits.

> or could I just use
> the alloc_xenheap_page() macro and let alloc_domheap_pages() deal with
> allocation details?

No, the explicit MEMF_bits restriction is required, unless you widen the MFN
arrays passed to dom0 userspace to contain uint64_t entries.

 -- Keir

  reply	other threads:[~2011-05-09 14:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30 18:04 [PATCH 0 of 3] xentrace updates Olaf Hering
2011-03-30 18:04 ` [PATCH 1 of 3] xentrace: correct formula to calculate t_info_pages Olaf Hering
2011-04-01 10:32   ` George Dunlap
2011-03-30 18:04 ` [PATCH 2 of 3] xentrace: use tbuf_size for overflow check Olaf Hering
2011-04-01 11:18   ` George Dunlap
2011-04-05 10:19     ` Olaf Hering
2011-04-07 13:50     ` Olaf Hering
2011-04-18 18:45     ` non-contiguous allocations Olaf Hering
2011-04-26 11:51       ` Jan Beulich
2011-05-06 10:25         ` Olaf Hering
2011-05-06 10:45           ` Jan Beulich
2011-05-06 18:12       ` Olaf Hering
2011-05-06 18:46         ` Keir Fraser
2011-05-07  8:39           ` Olaf Hering
2011-05-07 16:31             ` Keir Fraser
2011-05-09  8:30           ` Jan Beulich
2011-05-09  8:34             ` Keir Fraser
2011-05-09 12:43           ` Olaf Hering
2011-05-09 14:14             ` Keir Fraser [this message]
2011-03-30 18:04 ` [PATCH 3 of 3] xentrace: remove unneeded debug printk Olaf Hering
2011-04-01 11:18   ` George Dunlap

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=C9EDB542.18CDF%keir.xen@gmail.com \
    --to=keir.xen@gmail.com \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xensource.com \
    /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.