From: Ian Campbell <Ian.Campbell@XenSource.com>
To: Jan Beulich <jbeulich@novell.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: netfront pv driver building
Date: Wed, 24 Jan 2007 14:05:46 +0000 [thread overview]
Message-ID: <1169647546.6453.89.camel@localhost.localdomain> (raw)
In-Reply-To: <45B77139.76E4.0078.0@novell.com>
On Wed, 2007-01-24 at 13:46 +0000, Jan Beulich wrote:
> netfront requires the symbol __supported_pte_mask when PAE is enabled in the
> kernel being built for. That symbol, however, isn't being exported, and it doesn't
> seem likely that mainline would want to see this get exported (after all, the
> general assumption is that the page table handling inline functions and macros
> are supposed to be used only by the memory management code).
I committed a patch the other day which defines __supported_pte_mask to
~0ULL when building the unmodified drivers. It is 13555:687b1120765e in
xen-unstable. You are using 3.0.4-testing?
(it occurs to me now that I might have wanted ~PAGE_NX for greatest
compatibility, need to think about that a bit more.)
I wonder how this affects the PV-on-PV version when built as a module.
Presumably we export the symbol in the Xen tree but as you say that is
unlikely to go upstream.
> Additionally, both uses are inside a conditional depending upon
> !XENFEAT_auto_translated_physmap, which hence can't ever be true if this
> code is being built as pv driver. Wouldn't it hence make sense to #ifdef these
> code blocks, or to enhance xen/features.h so that checks for those features
> that are always on in hvm and return a constant 1 rather than using the
> xen_features array.
Is it necessary with the fix I mentioned above?
Ian.
next prev parent reply other threads:[~2007-01-24 14:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-24 13:46 netfront pv driver building Jan Beulich
2007-01-24 14:05 ` Ian Campbell [this message]
2007-01-24 14:23 ` Jan Beulich
2007-01-24 14:32 ` Keir Fraser
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=1169647546.6453.89.camel@localhost.localdomain \
--to=ian.campbell@xensource.com \
--cc=jbeulich@novell.com \
--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.