Quoting Zhi Wang (2017-08-14 13:04:34) > [ BACKGROUND ] > > Due to different guests will have different PPAT configuration under > virtualization environment, for example, Windows guest vs Linux guest, a > possible idea to handle this open is > > 1)Letting host have the PPAT entries needed by guest More or less requires static entries forevermore, locking the guest and host into not changing in future. That doesn't seem a viable assumption. > 2)Mapping PPAT indexes in guest page table to the corresponding host > PPAT entries during building the shadow page table. > > To achieve 1), one approach which has been used before is statically > adding the collection of guest PPAT configuration into host i915. So > when performing 2) GVT-g will always find an available PPAT entry to map. > > Another possible approach is GVT-g could dynamically find/add/delete the > PPAT configuration for different guests. To prevent regression of host > i915 due to this changes, it’s better to have two types of PPAT entry: > one is “static PPAT entry”, which is to keep current host i915 PPAT > configuration unchanged, e.g. the mapping between i915 cache level and > PPAT index, etc… just keep everything used by host i915 unchanged and a > *static* PPAT entry will not be modified. Seems reasonable, just something like: int intel_ppat_find(struct drm_i915_private *i915, struct ppat_config *opts); That can return the index of an existing ppat entry or assign new one (or error code, or a struct + ERR_PTR). And with a use-counter (intel_ppat_get/intel_ppat_put, where intel_ppat_find always returns with the use-counter preincremented) allows for reconfiguration. The downside is the remapping required, which I expect will not be too tricky? As you copy the PTE from the guest into the host you just run it through a translation table, right? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
