Re: CVS commit: src/sys/arch/x86

[Cherry G.Mathew <cherry%zyx.in@localhost>]

(resent to source-changes-d@)

"Maxime Villard" <maxv%netbsd.org@localhost> writes:


[...]

>
> Contrary to AMD-SVM, Intel-VMX uses a different set of PTE bits from
> native, and this has three important consequences:
>
>  - We can't use the native PTE bits, so each time we want to modify the
>    page tables, we need to know whether we're dealing with a native pmap
>    or an EPT pmap. This is accomplished with callbacks, that handle
>    everything PTE-related.
>

I like this approach - perhaps it's a way to separate out other similar
pmaps (OT).

>  - There is no recursive slot possible, so we can't use pmap_map_ptes().
>    Rather, we walk down the EPT trees via the direct map, and that's
>    actually a lot simpler (and probably faster too...).
>

Does this mean that nvmm hosts have to have __HAVE_DIRECT_MAP ?
If so, it might be worth having a separate kernel conf rather than
GENERIC (I don't know how this works now). I recently built an amd64
kernel without __HAVE_DIRECT_MAP and was quite impressed that it
actually booted. That's a nice to have feature.

>  - The kernel is never mapped in an EPT pmap. An EPT pmap cannot be loaded
>    on the host. This has two sub-consequences: at creation time we must
>    zero out all of the top-level PTEs, and at destruction time we force
>    the page out of the pool cache and into the pool, to ensure that a next
>    allocation will invoke pmap_pdp_ctor() to create a native pmap and not
>    recycle some stale EPT entries.

Can you not use a separate poolcache ? This could isolate host/guest
related memory pressure as well ?

-- 
~cherry