_PAGE_GNTTAB is set to use the 3th free bit of the page table entry (0x800).
In NetBSD/i386 it's defined as PG_X. After looking at the code a bit, i 
think it's used by the software execute-disable feature.
It hasn't always been in the code so i guess you can *theorically* 
remove it.
Would be easier if Xen actually provided execute-disable pages, we could 
remove this bit without any loss...
Execute-disable hardware support can be found on any new machine since 
about 2 years, but it requires PAE to be enabled.

Michael Richardson wrote:
> Re: http://mail-index.netbsd.org/port-xen/2006/09/12/0001.html
> and http://mail-index.netbsd.org/port-xen/2006/07/26/0007.html
>
> Frank van der Linden wrote:
>
> > From: Frank van der Linden <fvdl@netbsd.org>
> > List: port-xen
> > Date: 09/12/2006 21:06:56
> >
> > Anyway, this is just a note that I tracked down this problem. When
> > compiled with debugging options on, Xen uses an unused PTE bit to track
> > granted table pages, in an effort to catch cleanup problems early.
> > However, the NetBSD pmap already uses all of those bits. So, at the
> > first attempt to enter a tracked (pv_list) mapping, Xen refuses, 
> because
> > the same bit it is using for debugging purposes is set in the PTE. The
> > definition (_PAGE_GNTTAB) is even marked as "has to be disabled for 
> *BSD").
>
> > I guess there are Xen compiles out there that have debug on by default,
> > and with the current Xen sources, NetBSD (and *BSD in general), won't
> > boot on that.
>
> Is the use of all PTE bits an absolute in NetBSD (we can never fix this),
> or is there some bit of work that has not yet been done?
>
> I ask because Fedora Core certainly ships with hypervisor debugging on,
> and it would be nice to be able to run NetBSD guests on "stock" 
> Xen-capable systems.
>
> If we can never fix this in NetBSD --- that's fine, I'll build my own 
> hypervisor
> kernel. But, it will become a major PITA as Xen becomes more popular.
>
>
>
>
>