All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [RFC] Introduce dynamic PPAT allocation for GVT-g
  2017-08-14 12:04 [RFC] Introduce dynamic PPAT allocation for GVT-g Zhi Wang
@ 2017-08-14 10:31 ` Chris Wilson
  0 siblings, 0 replies; 2+ messages in thread
From: Chris Wilson @ 2017-08-14 10:31 UTC (permalink / raw)
  To: Zhi Wang, intel-gfx

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [RFC] Introduce dynamic PPAT allocation for GVT-g
@ 2017-08-14 12:04 Zhi Wang
  2017-08-14 10:31 ` Chris Wilson
  0 siblings, 1 reply; 2+ messages in thread
From: Zhi Wang @ 2017-08-14 12:04 UTC (permalink / raw)
  To: intel-gfx

[ 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

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.

Another type is “dynamic PPAT entry”, which will be managed by GVT-g.

[ EXPECTED CHANGE OF HOST i915 ]

Since i915 doesn’t need dynamic PPAT allocation, one idea is putting all 
the dynamic PPAT entry management in GVT-g, i915 shows a bitmap of 
available PPAT indexes to GVT-g after initializing host PPAT entries, so 
GVT-g could manage them on-demand.

Thanks,
Zhi.
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-08-14 10:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-14 12:04 [RFC] Introduce dynamic PPAT allocation for GVT-g Zhi Wang
2017-08-14 10:31 ` Chris Wilson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.