[Intel-gfx] [RFC] Introduce dynamic PPAT allocation for GVT-g
Chris Wilson
chris at chris-wilson.co.uk
Mon Aug 14 10:31:47 UTC 2017
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
More information about the Intel-gfx
mailing list