(resent to source-changes-d@) "Maxime Villard" <m...@netbsd.org> 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
