WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] netfront pv driver building

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] netfront pv driver building
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Wed, 24 Jan 2007 14:05:46 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 24 Jan 2007 06:05:36 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45B77139.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <45B77139.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>