Hypervisor issues with PTE

_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 <fvdlnetbsd.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.
>
>
>
>
>

Mathieu Ropert wrote:
> _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.

So... maybe disabling the execute-disable feature might
work.
I think that there aren't any more free bits, so, unless the
hypervisor provides
this one would have to live without.

I wonder what happens if I #define PG_X 0 

Mathieu Ropert wrote:
> _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.

So... maybe disabling the execute-disable feature might
work.
I think that there aren't any more free bits, so, unless the
hypervisor provides
this one would have to live without.

I wonder what happens if I #define PG_X 0 

Array

Array