Re: [PATCH 1/2] drm/i915: Support per-PPGTT address space mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 26, 2016 at 04:17:51PM +0100, Matthew Auld wrote:
> From: "Wang, Zhi A" <zhi.a.wang@xxxxxxxxx>
> 
> Previously the address space mode of each PPGTT instance is hard-coded to
> host system configuration, e.g. if the host system is configured to use
> 48bit full PPGTT, then address space mode of all PPGTT instances is 48bit.
> 
> Per Daniel and Kevin's advice, GVT-g will leverage i915 PPGTT interface to
> populate its shadow PPGTT page table. Under GVT-g the address space mode
> of PPGTT instances could be various, some guest may use 32bit, some guest
> may use 48bit.
> 
> We store the address space mode into i915_hw_ppgtt, and let i915 page
> table manipulation routines / LRC context population routines read the
> address space mode from it instead of the system configuration.
> 
> v2:
> (Matthew Auld)
>   - rebase on latest -nightly
>   - prefer i915_vm_to_ppgtt instead of container_of
>   - initialise address_space_mode _before_ we attempt to init
>     scratch, otherwise breakage will ensue

Worth adding each address space type (i915.enable_ppgtt=) to
drv_module_reload_basic ? Probably better to add new a module loader
test to exercise these nondefault flags that can find bugs without
overburdening BAT.

This patch could be split up into the feeding of pggtt instead of dev
and then we see the impact of switchable address modes more clearly.

>  #define I915_PDPES_PER_PDP(dev) (USES_FULL_48BIT_PPGTT(dev) ?\
>  				 GEN8_PML4ES_PER_PML4 : GEN8_LEGACY_PDPES)
> +#define IS_48BIT_PPGTT(ppgtt)	((ppgtt) && ((ppgtt)->address_space_mode == 48))
>  
>  #define PPAT_UNCACHED_INDEX		(_PAGE_PWT | _PAGE_PCD)
>  #define PPAT_CACHED_PDE_INDEX		0 /* WB LLC */
> @@ -372,6 +373,8 @@ struct i915_hw_ppgtt {
>  		struct i915_page_directory pd;		/* GEN6-7 */
>  	};
>  
> +	int address_space_mode;

The only question is why int, and why 48 rather than either a boolean
flag or an enum?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux