drm/i915/gvt: merge gvt.c into kvmgvt.c

The code in both files is deeply interconnected, so merge it and
keep a bunch of structures and functions static.

Signed-off-by: Christoph Hellwig <[email protected]

drm/i915/gvt: merge gvt.c into kvmgvt.c

The code in both files is deeply interconnected, so merge it and
keep a bunch of structures and functions static.

Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Zhi Wang <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jason Gunthorpe <[email protected]>
Reviewed-by: Zhi Wang <[email protected]>

show more ...

drm/i915/gvt: move the gvt code into kvmgt.ko

Instead of having an option to build the gvt code into the main i915
module, just move it into the kvmgt.ko module. This only requires
a new struct wit

drm/i915/gvt: move the gvt code into kvmgt.ko

Instead of having an option to build the gvt code into the main i915
module, just move it into the kvmgt.ko module. This only requires
a new struct with three entries that the KVMGT modules needs to register
with the main i915 module, and a proper list of GVT-enabled devices
instead of global device pointer.

Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Zhi Wang <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jason Gunthorpe <[email protected]>
Reviewed-by: Zhi Wang <[email protected]>

show more ...

drm/i915/gvt: better align the Makefile with i915 Makefile

Drop extra ccflags, drop extra intermediate variables, list object files
one per line alphabetically.

Cc: Zhi Wang <[email protected]

drm/i915/gvt: better align the Makefile with i915 Makefile

Drop extra ccflags, drop extra intermediate variables, list object files
one per line alphabetically.

Cc: Zhi Wang <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Zhi Wang <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/8bc0895376c077156a671e24ac6a5c75b7db4c9c.1649852517.git.jani.nikula@intel.com
Reviewed-by: Zhi Wang <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>

show more ...

drm: prefix header search paths with $(srctree)/

Currently, the Kbuild core manipulates header search paths in a crazy
way [1].

To fix this mess, I want all Makefiles to add explicit $(srctree)/ to

drm: prefix header search paths with $(srctree)/

Currently, the Kbuild core manipulates header search paths in a crazy
way [1].

To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.

Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").

[1]: https://patchwork.kernel.org/patch/9632347/

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: James Qian Wang (Arm Technology China) <[email protected]>
Acked-by: Liviu Dudau <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

drm/i915/gvt: Change KVMGT as self load module

This trys to make 'kvmgt' module as self loadable instead of loading
by i915/gvt device model. So hypervisor specific module could be
stand-alone, e.g

drm/i915/gvt: Change KVMGT as self load module

This trys to make 'kvmgt' module as self loadable instead of loading
by i915/gvt device model. So hypervisor specific module could be
stand-alone, e.g only after loading hypervisor specific module, GVT
feature could be enabled via specific hypervisor interface, e.g VFIO/mdev.

So this trys to use hypervisor module register/unregister interface
for that. Hypervisor module needs to take care of module reference
itself when working for hypervisor interface, e.g for VFIO/mdev,
hypervisor module would reference counting mdev when open and release.

This makes 'kvmgt' module really split from GVT device model. User
needs to load 'kvmgt' to enable VFIO/mdev interface.

v6:
- remove unused variable

v5:
- put module reference in register error path

v4:
- fix checkpatch warning

v3:
- Fix module reference handling for device open and release. Unused
mdev devices would be cleaned up in device unregister when module unload.

v2:
- Fix kvmgt order after i915 for built-in case

Cc: "Yuan, Hang" <[email protected]>
Cc: Alex Williamson <[email protected]>
Cc: "He, Min" <[email protected]>
Reviewed-by: Yuan, Hang <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: Provide generic page_track infrastructure for write-protected page

This patch provide generic page_track infrastructure for write-protected
guest page. The old page_track logic gets re

drm/i915/gvt: Provide generic page_track infrastructure for write-protected page

This patch provide generic page_track infrastructure for write-protected
guest page. The old page_track logic gets rewrote and now stays in a new
standalone page_track.c. This page track infrastructure can be both used
by vGUC and GTT shadowing.

The important change is that it uses radix tree instead of hash table.
We don't have a predictable number of pages that will be tracked.

Here is some performance data (duration in us) of looking up a element:
Before: (aka. intel_vgpu_find_tracked_page)
0.091 0.089 0.090 ... 0.093 0.091 0.087 ... 0.292 0.285 0.292 0.291
After: (aka. intel_vgpu_find_page_track)
0.104 0.105 0.100 0.102 0.102 0.100 ... 0.101 0.101 0.105 0.105

The hash table has good performance at beginning, but turns bad with
more pages being tracked even no 3D applications are running. As
expected, radix tree has stable duration and very quick.

The overall benchmark (tested with Heaven Benchmark) marginally improved
since this is not the bottleneck. What we benefit more from this change
is scalability.

Signed-off-by: Changbin Du <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: Rename file render.{c, h} to mmio_context.{c, h}

Rename the files to reflect their real role - to switch the mmio context of
each vGPU engine.

v2: update Makefile.

Signed-off-by: Cha

drm/i915/gvt: Rename file render.{c, h} to mmio_context.{c, h}

Rename the files to reflect their real role - to switch the mmio context of
each vGPU engine.

v2: update Makefile.

Signed-off-by: Changbin Du <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: Dmabuf support for GVT-g

This patch introduces a guest's framebuffer sharing mechanism based on
dma-buf subsystem. With this sharing mechanism, guest's framebuffer can
be shared betwee

drm/i915/gvt: Dmabuf support for GVT-g

This patch introduces a guest's framebuffer sharing mechanism based on
dma-buf subsystem. With this sharing mechanism, guest's framebuffer can
be shared between guest VM and host.

v17:
- modify VFIO_DEVICE_GET_GFX_DMABUF interface. (Alex)

v16:
- add x_hot and y_hot. (Gerd)
- add flag validation for VFIO_DEVICE_GET_GFX_DMABUF. (Alex)
- rebase 4.14.0-rc6.

v15:
- add VFIO_DEVICE_GET_GFX_DMABUF ABI. (Gerd)
- add intel_vgpu_dmabuf_cleanup() to clean up the vGPU's dmabuf. (Gerd)

v14:
- add PROBE, DMABUF and REGION flags. (Alex)

v12:
- refine the lifecycle of dmabuf.

v9:
- remove dma-buf management. (Alex)
- track the dma-buf create and release in kernel mode. (Gerd) (Daniel)

v8:
- refine the dma-buf ioctl definition.(Alex)
- add a lock to protect the dmabuf list. (Alex)

v7:
- release dma-buf related allocations in dma-buf's associated release
function. (Alex)
- refine ioctl interface for querying plane info or create dma-buf.
(Alex)

v6:
- align the dma-buf life cycle with the vfio device. (Alex)
- add the dma-buf related operations in a separate patch. (Gerd)
- i915 related changes. (Chris)

v5:
- fix bug while checking whether the gem obj is gvt's dma-buf when user
change caching mode or domains. Add a helper function to do it.
(Xiaoguang)
- add definition for the query plane and create dma-buf. (Xiaoguang)

v4:
- fix bug while checking whether the gem obj is gvt's dma-buf when set
caching mode or doamins. (Xiaoguang)

v3:
- declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object
to represent the gem obj for gvt's dma-buf. The tiling mode, caching
mode and domains can not be changed for this kind of gem object. (Alex)
- change dma-buf related information to be more generic. So other vendor
can use the same interface. (Alex)

v2:
- create a management fd for dma-buf operations. (Alex)
- alloc gem object's backing storage in gem obj's get_pages() callback.
(Chris)

Signed-off-by: Tina Zhang <[email protected]>
Cc: Alex Williamson <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Gerd Hoffmann <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: Add framebuffer decoder support

This patch is to introduce the framebuffer decoder which can decode guest
OS's framebuffer information, including primary, cursor and sprite plane.

v16

drm/i915/gvt: Add framebuffer decoder support

This patch is to introduce the framebuffer decoder which can decode guest
OS's framebuffer information, including primary, cursor and sprite plane.

v16:
- rebase to 4.14.0-rc6.

v14:
- refine pixel format table. (Zhenyu)

v9:
- move drm format change to a separate patch. (Xiaoguang)

v8:
- fix a bug in decoding primary plane. (Tina)

v7:
- refine framebuffer decoder code. (Zhenyu)

Signed-off-by: Tina Zhang <[email protected]>
Cc: Zhenyu Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: Add basic debugfs infrastructure

We need debugfs entry to expose some debug information of gvt and vGPUs.
The first tool will be added is mmio-diff, which help to find the
difference v

drm/i915/gvt: Add basic debugfs infrastructure

We need debugfs entry to expose some debug information of gvt and vGPUs.
The first tool will be added is mmio-diff, which help to find the
difference values of host and vGPU mmio. It's useful for platform
enabling.

This patch just add a basic debugfs infrastructure, each vGPU has its own
sub-folder. Two simple attributes are created as a template.
.
├── num_tracked_mmio
├── vgpu1
| └── active
└── vgpu2
└── active

Signed-off-by: Changbin Du <[email protected]>
Reviewed-by: Zhi Wang <[email protected]>
Signed-off-by: Zhi Wang <[email protected]>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drm/i915/gvt: remove redundant -Wall

This flag is already set in the top level Makefile of the kernel.

Also, by having set CONFIG_DRM_I915_GVT, thereby appending -Wall to
ccflags, you undo all the

drm/i915/gvt: remove redundant -Wall

This flag is already set in the top level Makefile of the kernel.

Also, by having set CONFIG_DRM_I915_GVT, thereby appending -Wall to
ccflags, you undo all the -Wno-* cflags previously set in the Make
variable KBUILD_CFLAGS.

For example:

cc foo.c -Wall -Wno-format -Wall

resets -Wformat.

Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT

KVMGT leverages vfio/mdev to mediate device accesses from guest,
this patch adds the vfio/mdev support, thereby completes the
functionality. An int

drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT

KVMGT leverages vfio/mdev to mediate device accesses from guest,
this patch adds the vfio/mdev support, thereby completes the
functionality. An intel_vgpu is presented as a mdev device,
and full userspace API compatibility with vfio-pci is kept.
An intel_vgpu_ops is provided to mdev framework, methods get
called to create/remove a vgpu, to open/close it, and to
access it.

Signed-off-by: Kevin Tian <[email protected]>
Signed-off-by: Xiaoguang Chen <[email protected]>
Signed-off-by: Jike Song <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: add KVMGT support

KVMGT is the MPT implementation based on VFIO/KVM. It provides
a kvmgt_mpt ops to gvt for vGPU access mediation, e.g. to
mediate and emulate the MMIO accesses, to inj

drm/i915/gvt: add KVMGT support

KVMGT is the MPT implementation based on VFIO/KVM. It provides
a kvmgt_mpt ops to gvt for vGPU access mediation, e.g. to
mediate and emulate the MMIO accesses, to inject interrupts
to vGPU user, to intercept the GTT writing and replace it with
DMA-able address, to write-protect guest PPGTT table for
shadowing synchronization, etc. This patch provides the MPT
implementation for GVT, not yet functional due to theabsence
of mdev.

It's built as kvmgt.ko, depends on vfio.ko, kvm.ko and mdev.ko,
and being required by i915.ko. To not introduce hard dependency
in i915.ko, we used indirect symbol reference. But that means
users have to include kvmgt.ko into init ramdisk if their
i915.ko is included.

Signed-off-by: Kevin Tian <[email protected]>
Signed-off-by: Xiaoguang Chen <[email protected]>
Signed-off-by: Jike Song <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU command scanner

This patch introduces a command scanner to scan guest command buffers.

Signed-off-by: Yulei Zhang <[email protected]>
Signed-off-by: Zhi Wang <zhi.a.wang@inte

drm/i915/gvt: vGPU command scanner

This patch introduces a command scanner to scan guest command buffers.

Signed-off-by: Yulei Zhang <[email protected]>
Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU context switch

As different VM may configure different render MMIOs when executing
workload, to schedule workloads between different VM, the render MMIOs
have to be switched.

Sig

drm/i915/gvt: vGPU context switch

As different VM may configure different render MMIOs when executing
workload, to schedule workloads between different VM, the render MMIOs
have to be switched.

Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU schedule policy framework

This patch introduces a vGPU schedule policy framework, with a timer based
schedule policy module for now

Signed-off-by: Zhi Wang <[email protected]>

drm/i915/gvt: vGPU schedule policy framework

This patch introduces a vGPU schedule policy framework, with a timer based
schedule policy module for now

Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU workload scheduler

This patch introduces the vGPU workload scheduler routines.

GVT workload scheduler is responsible for picking and executing GVT workload
from current scheduled

drm/i915/gvt: vGPU workload scheduler

This patch introduces the vGPU workload scheduler routines.

GVT workload scheduler is responsible for picking and executing GVT workload
from current scheduled vGPU. Before the workload is submitted to host i915,
the guest execlist context will be shadowed in the host GVT shadow context.
the instructions in guest ring buffer will be copied into GVT shadow ring
buffer. Then GVT-g workload scheduler will scan the instructions in guest
ring buffer and submit it to host i915.

Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU execlist virtualization

This patch introduces the vGPU execlist virtualization.

Under virtulization environment, HW execlist interface are fully emulated
including virtual CSB em

drm/i915/gvt: vGPU execlist virtualization

This patch introduces the vGPU execlist virtualization.

Under virtulization environment, HW execlist interface are fully emulated
including virtual CSB emulation, virtual execlist emulation. The framework
will emulate the virtual CSB according to the guest workload running status

Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU display virtualization

This patch introduces the GVT-g display virtualization.

It consists a collection of display MMIO handlers, like power well register
handler, pipe register

drm/i915/gvt: vGPU display virtualization

This patch introduces the GVT-g display virtualization.

It consists a collection of display MMIO handlers, like power well register
handler, pipe register handler, plane register handler, which will emulate
all display MMIOs behavior to support virtual mode setting sequence for
guest.

Signed-off-by: Bing Niu <[email protected]>
Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU MMIO virtualization

This patch introduces the generic vGPU MMIO emulation intercept
framework. The MPT modules will request GVT-g core logic to
emulate MMIO read/write through IO

drm/i915/gvt: vGPU MMIO virtualization

This patch introduces the generic vGPU MMIO emulation intercept
framework. The MPT modules will request GVT-g core logic to
emulate MMIO read/write through IO emulation operations
callback when hypervisor trapped a guest GTTMMIO read/write.

Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU PCI configuration space virtualization

This patch introduces vGPU PCI configuration space virtualization.

- Adjust the trapped GPFN(Guest Page Frame Number) window of virtual GEN

drm/i915/gvt: vGPU PCI configuration space virtualization

This patch introduces vGPU PCI configuration space virtualization.

- Adjust the trapped GPFN(Guest Page Frame Number) window of virtual GEN
PCI BAR 0 when guest initializes PCI BAR 0 address.

- Emulate OpRegion when guest touches OpRegion.

- Pass-through a part of aperture to guest when guest initializes
aperture BAR.

Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU graphics memory virtualization

The vGPU graphics memory emulation framework is responsible for graphics
memory table virtualization. Under virtualization environment, a VM will
po

drm/i915/gvt: vGPU graphics memory virtualization

The vGPU graphics memory emulation framework is responsible for graphics
memory table virtualization. Under virtualization environment, a VM will
populate the page table entry with guest page frame number(GPFN/GFN), while
HW needs a page table filled with MFN(Machine frame number). The
relationship between GFN and MFN(Machine frame number) is managed by
hypervisor, while GEN HW doesn't have such knowledge to translate a GFN.

To solve this gap, shadow GGTT/PPGTT page table is introdcued.

For GGTT, the GFN inside the guest GGTT page table entry will be translated
into MFN and written into physical GTT MMIO registers when guest write
virtual GTT MMIO registers.

For PPGTT, a shadow PPGTT page table will be created and write-protected
translated from guest PPGTT page table. And the shadow page table root
pointers will be written into the shadow context after a guest workload
is shadowed.

vGPU graphics memory emulation framework consists:

- Per-GEN HW platform page table entry bits extract/de-extract routines.
- GTT MMIO register emulation handlers, which will call hypercall to do
GFN->MFN translation when guest write GTT MMIO register
- PPGTT shadow page table routines, e.g. shadow create/destroy/out-of-sync

Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: vGPU interrupt virtualization.

This patch introduces vGPU interrupt emulation framework.

The vGPU intrerrupt emulation framework is an event-based interrupt
emulation framework. It's

drm/i915/gvt: vGPU interrupt virtualization.

This patch introduces vGPU interrupt emulation framework.

The vGPU intrerrupt emulation framework is an event-based interrupt
emulation framework. It's responsible for emulating GEN hardware interrupts
during emulating other HW behaviour.

It consists several components:

- Descriptions of interrupt register bit
- Upper level <-> lower level interrupt mapping
- GEN HW IER/IMR/IIR register emulation routines
- Event-based interrupt propagation interface

When a GVT-g component wants to inject an interrupt to a VM during a
emulation, first it should specify the event needs to be emulated and the
framework will deal with the rest of emulation:

- Generating related virtual IIR bit according to virtual IER and IMRs,
- Generate related virtual upper level virtual IIR bit accodring to the
per-platform interrupt mapping
- Injecting a MSI to VM

Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>

show more ...

drm/i915/gvt: trace stub

v2:
- Make checkpatch.pl happy(Joonas)

Signed-off-by: Zhi Wang <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>