- 30 Jul, 2019 1 commit
-
-
Zhenyu Wang authored
This removes duplicate include of trace.h. Found by Hariprasad Kelam with includecheck. Reported-by:
Hariprasad Kelam <hariprasad.kelam@gmail.com> Reviewed-by:
Yan Zhao <yan.y.zhao@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
- 14 Oct, 2016 3 commits
-
-
Zhi Wang authored
v2: - Make checkpatch.pl happy(Joonas) Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
-
Zhi Wang authored
A vGPU represents a virtual Intel GEN hardware, which consists following virtual resources: - Configuration space (virtualized) - HW registers (virtualized) - GGTT memory space (partitioned) - GPU page table (shadowed) - Fence registers (partitioned) * virtualized: fully emulated by GVT-g. * partitioned: Only a part of the HW resource is allowed to be accessed by VM. * shadowed: Resource needs to be translated and shadowed before getting applied into HW. This patch introduces vGPU life cycle management framework, which is responsible for creating/destroying a vGPU and preparing/free resources related to a vGPU. Signed-off-by:
-
Zhi Wang authored
This patch introduces the GVT-g vGPU HW resource management. Under GVT-g virtualizaion environment, each vGPU requires portions HW resources, including aperture, hidden GM space, and fence registers. When creating a vGPU, GVT-g will request these HW resources from host, and return them to host after a vGPU is destroyed. Signed-off-by:
-
- 17 Jun, 2016 3 commits
-
-
Zhi Wang authored
This patch introduces the very basic framework of GVT-g device model, includes basic prototypes, definitions, initialization. v12: - Call intel_gvt_init() in driver early initialization stage. (Chris) v8: - Remove the GVT idr and mutex in intel_gvt_host. (Joonas) v7: - Refine the URL link in Kconfig. (Joonas) - Refine the introduction of GVT-g host support in Kconfig. (Joonas) - Remove the macro GVT_ALIGN(), use round_down() instead. (Joonas) - Make "struct intel_gvt" a data member in struct drm_i915_private.(Joonas) - Remove {alloc, free}_gvt_device() - Rename intel_gvt_{create, destroy}_gvt_device() - Expost intel_gvt_init_host() - Remove the dummy "struct intel_gvt" declaration in intel_gvt.h (Joonas) v6: - Refine introduction in Kconfig. (Chris) - The exposed API functions will take struct intel_gvt * instead of void *. (Chris/Tvrtko) - Remove most memebers of strct intel_gvt_device_info. Will add them in the device model patches.(Chris) - Remove gvt_info() and gvt_err() in debug.h. (Chris) - Move GVT kernel parameter into i915_params. (Chris) - Remove include/drm/i915_gvt.h, as GVT-g will be built within i915. - Remove the redundant struct i915_gvt *, as the functions in i915 will directly take struct intel_gvt *. - Add more comments for reviewer. v5: Take Tvrtko's comments: - Fix the misspelled words in Kconfig - Let functions take drm_i915_private * instead of struct drm_device * - Remove redundant prints/local varible initialization v3: Take Joonas' comments: - Change file name i915_gvt.* to intel_gvt.* - Move GVT kernel parameter into intel_gvt.c - Remove redundant debug macros - Change error handling style - Add introductions for some stub functions - Introduce drm/i915_gvt.h. Take Kevin's comments: - Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c v2: - Introduce i915_gvt.c. It's necessary to introduce the stubs between i915 driver and GVT-g host, as GVT-g components is configurable in kernel config. When disabled, the stubs here do nothing. Take Joonas' comments: - Replace boolean return value with int. - Replace customized info/warn/debug macros with DRM macros. - Document all non-static functions like i915. - Remove empty and unused functions. - Replace magic number with marcos. - Set GVT-g in kernel config to "n" by default. Reviewed-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Zhi Wang authored
v5: - Let functions take struct drm_i915_private *. (Tvrtko) - Fold vGPU related active check into the inner functions. (Kevin) Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
Kevin Tian <kevin.tian@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by:
-
Zhi Wang authored
As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g host (GVT-g kernel device model), factor it out for better code structure. v7: - Split the "offsetof" modification into a dedicated patch. (Joonas) v3: - Use offsetof to calculate the member offset of PVINFO structure (Joonas) Reviewed-by:
-
- 10 May, 2016 1 commit
-
-
Chris Wilson authored
Pass drm_i915_private to the uncore init/fini routines and their subservients as it is their native type. text data bss dec hex filename 6309978 3578778 696320 10585076 a183f4 vmlinux 6309530 3578778 696320 10584628 a18234 vmlinux a modest 400 bytes of saving, but 60 lines of code deleted! Signed-off-by:
-
- 18 Nov, 2015 2 commits
-
-
Ville Syrjälä authored
Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
We'll want to avoid performing arithmetic with register offsets, so instead calculating the vgpu PDP as pdp0_lo+offset, make the PDPs into an array. This way we can simply loop through them. Cc: Eddie Dong <eddie.dong@intel.com> Cc: Jike Song <jike.song@intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Yu Zhang <yu.c.zhang@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Zhiyuan Lv <zhiyuan.lv@intel.com> Signed-off-by:
Zhiyuan Lv <zhiyuan.lv@intel.com>
-
- 02 Sep, 2015 1 commit
-
-
Zhiyuan Lv authored
Some more definitions in the PV info page are added. They are mainly for the guest notification to Intel GVT-g device model. They are used for Broadwell enabling. The notification of PPGTT page table creation/destroy is to notify GVT-g device model the life cycle of guest page tables. Then device model will implement shadow page table for guests. The notification of context create/destroy is optional. If it is used, the device model will create/destroy shadow context corresponding to the context's life cycle. Guest driver needs to make sure that the context's LRCA and backing storage address unchanged. If it is not used, the device model will perform the context shadow work in the context scheduling time. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 Mar, 2015 1 commit
-
-
Daniel Vetter authored
Without this Dave's 32bit rhel compiler is annoyed. Don't ask me about the exact rules for this stuff though, but this should be safe. Reported-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
- 13 Feb, 2015 3 commits
-
-
Yu Zhang authored
Display switch logic is added to notify the host side that current vGPU have a valid surface to show. It does so by writing the display_ready field in PV INFO page, and then will be handled in the host side. This is useful to avoid trickiness when the VM's framebuffer is being accessed in the middle of VM modesetting, e.g. compositing the framebuffer in the host side. v2: - move the notification code outside the 'else' in load sequence - remove the notification code in intel_crtc_set_config() v4: - code rebase, no need to define another dev_priv - use #define instead of enum for display readiness Signed-off-by:Yu Zhang <yu.c.zhang@linux.intel.com> Signed-off-by:
Jike Song <jike.song@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Yu Zhang authored
With Intel GVT-g, the global graphic memory space is partitioned by multiple vGPU instances in different VMs. The ballooning code is called in i915_gem_setup_global_gtt(), utilizing the drm mm allocator APIs to mark the graphic address space which are partitioned out to other vGPUs as reserved. With ballooning, host side does not need to translate a grahpic address from guest view to host view. By now, current implementation only support the static ballooning, but in the future, with more cooperation from guest driver, the same interfaces can be extended to grow/shrink the guest graphic memory dynamically. v2: take Chris and Daniel's comments: - no guard page between different VMs - use drm_mm_reserve_node() to do the reservation for ballooning, instead of the previous drm_mm_insert_node_in_range_generic() v3: take Daniel's comments: - move ballooning functions into i915_vgpu.c - add kerneldoc to ballooning functions v4: take Tvrtko's comments: - more accurate comments and commit message Signed-off-by:
Eddie Dong <eddie.dong@intel.com> Reviewed-by:
-
Yu Zhang authored
Introduce a PV INFO structure, to facilitate the Intel GVT-g technology, which is a GPU virtualization solution with mediated pass-through. This page contains the shared information between i915 driver and the host emulator. For now, this structure utilizes an area of 4K bytes on HSW GPU's unused MMIO space. Future hardware will have the reserved window architecturally defined, and layout of the page will be added in future BSpec. The i915 driver load routine detects if it is running in a VM by reading the contents of this PV INFO page. Thereafter a flag, vgpu.active is set, and intel_vgpu_active() is used by checking this flag to conclude if GPU is virtualized with Intel GVT-g. By now, intel_vgpu_active() will return true, only when the driver is running as a guest in the Intel GVT-g enhanced environment on HSW platform. v2: take Chris' comments: - call the i915_check_vgpu() in intel_uncore_init() - sanitize i915_check_vgpu() by adding BUILD_BUG_ON() and debug info take Daniel's comments: - put the definition of PV INFO into a new header - i915_vgt_if.h other changes: - access mmio regs by readq/readw in i915_check_vgpu() v3: take Daniel's comments: - move the i915/vgt interfaces into a new i915_vgpu.c - update makefile - add kerneldoc to functions which are non-static - add a DOC: section describing some of the high-level design - update drm docbook other changes: - rename i915_vgt_if.h to i915_vgpu.h v4: take Tvrtko's comments: - fix a typo in commit message - add debug message when vgt version mismatches - rename low_gmadr/high_gmadr to mappable/non-mappable in PV INFO structure Signed-off-by:
-
