As noticed by Dan, there is useless (and incorrect) code in kvmgt trying
to kfree(NULL), though almost harmless. It was a copy-paste mistake and
should be removed.
Reported-by: Dan Carpenter
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 7 ---
1 file changed, 7 deletions
On 01/26/2017 02:50 PM, Dan Carpenter wrote:
> Hello Jike Song,
>
> The patch 659643f7d814: "drm/i915/gvt/kvmgt: add vfio/mdev support to
> KVMGT" from Dec 8, 2016, leads to the following static checker
> warning:
>
> drivers/gpu/drm/i915/gvt/kvmgt.c:969
Williamson
> ---
>
> This should really be fixed before initial release in v4.10
Acked-by: Jike Song
Thanks for finding this!
--
Thanks,
Jike
>
> drivers/gpu/drm/i915/gvt/kvmgt.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/driver
On 01/10/2017 02:52 PM, Zhenyu Wang wrote:
> Previously intel_gvt_init() was called very early even before
> MMIO initialization which had several drawbacks:
> - Have to handle MMIO access for initial MMIO state dump if golden
> state firmware is not available
> - Hypervisor detection should depe
On 01/11/2017 10:40 AM, Zhenyu Wang wrote:
> On 2017.01.11 10:18:30 +0800, Jike Song wrote:
>> On 01/10/2017 02:52 PM, Zhenyu Wang wrote:
>>> Prepare to remove detect_host() hook. Move intel iommu detection early
>>> in intel_gvt_init().
>>>
>>> Sig
On 01/10/2017 02:52 PM, Zhenyu Wang wrote:
> Prepare to remove detect_host() hook. Move intel iommu detection early
> in intel_gvt_init().
>
> Signed-off-by: Zhenyu Wang
> ---
> drivers/gpu/drm/i915/gvt/gvt.c | 7 +++
> drivers/gpu/drm/i915/gvt/kvmgt.c | 6 --
> 2 files changed, 7 inse
uct nor should it be considered one. Extra care should be taken
when testing and configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 07/20/2016 12:52 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for KVM.
>
> Intel GVT-g f
work in progress. As such it is
not a complete product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 07/22/2016 01:42 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another
complete product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 04/28/2016 01:29 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for Xen.
&
be taken
when testing and configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 04/16/2016 02:31 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for KVM.
>
> Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualiza
product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 01/27/2016 02:21 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for Xen.
>
> Intel GVT
On 04/21/2016 06:44 AM, cac...@quantum-sci.com wrote:
>
> No one will just come out and just tell us the truth, so that users can quit
> wasting our time trying to make your Xen work. Your 4.2 kernel dumps core on
> i915, and Xen hangs on disk drive ID.
>
> Why don't you just take down the Xen
ote:
The KVMGT project should be considered a work in progress. As such it is not a
complete product nor should it be considered one. Extra care should be taken
when testing and configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 01/27/2016 02:32 PM, Jike Song wrote:
> Hi all,
&
such it is
not a complete product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 10/27/2015 05:36 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-
/blogs/srclarkx/2013/graphics-virtualization-xengt
Note: The XenGT project should be considered a work in progress. As such it is
not a complete product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 11/27/2015 01:10 AM, Oleksii Kurochko wrote:
Hello all,
Do you have any ideas about previously mentioned question?
With best regards,
Oleksii
On Tue, Nov 24, 2015 at 6:48 PM, Oleksii Kurochko mailto:oleksii.kuroc...@globallogic.com>> wrote:
Hi all,
I am trying to enable XenGT fo
On 11/21/2015 01:25 AM, Alex Williamson wrote:
On Fri, 2015-11-20 at 08:10 +, Tian, Kevin wrote:
Here is a more concrete example:
KVMGT doesn't require IOMMU. All DMA targets are already replaced with
HPA thru shadow GTT. So DMA requests from GPU all contain HPAs.
When IOMMU is enabled, o
On 11/21/2015 12:40 AM, Alex Williamson wrote:
Thanks for confirmation. For QEMU/KVM, I totally agree your point; However,
if we take XenGT to consider, it will be a bit more complex: with Xen
hypervisor and Dom0 kernel running in different level, it's not a straight-
forward way for QEMU to do
On 11/20/2015 12:22 PM, Alex Williamson wrote:
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In addition to Kevin's replies, I have a high-level question: can VFIO
be used by QEMU for both KVM an
On 11/19/2015 07:09 PM, Paolo Bonzini wrote:
On 19/11/2015 09:40, Gerd Hoffmann wrote:
But this code should be
minor to be maintained in libvirt.
As far I know libvirt only needs to discover those devices. If they
look like sr/iov devices in sysfs this might work without any changes to
libvirt
Hi Alex,
On 11/19/2015 12:06 PM, Tian, Kevin wrote:
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, November 19, 2015 2:12 AM
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
{snip}
Hi!
At redhat we've been thinking about h
configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 12/04/2014 10:24 AM, Jike Song wrote:
Hi all,
We are pleased to announce the first release of KVMGT project. KVMGT is the
implementation of Intel GVT-g technology, a full GPU virtualization solution.
Under Intel GVT-g, a virtual
uch it is not
a complete product nor should it be considered one. Extra care should be taken
when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 07/07/2015 10:49 AM, Jike Song wrote:
Hi all,
We're pleased to announce a public update to Intel Graphics Virtuali
t nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 04/10/2015 09:23 PM, Jike Song wrote:
Hi all,
We're pleased to announce a public update to Intel Graphics Virtualization
Technology (I
Whoops. Changed the title from "2015-Q1" to be "2014-Q4" :)
--
Thanks,
Jike
On 01/09/2015 04:51 PM, Jike Song wrote:
Hi all,
We're pleased to announce a public update to Intel Graphics Virtualization
Technology (Intel GVT-g, formerly known as XenGT). Intel
ments!
--
Thanks,
Jike
On 12/04/2014 10:45 AM, Jike Song wrote:
Hi all,
We're pleased to announce a public release to Intel Graphics Virtualization
Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete
vGPU solution with mediated pass-through, supported today on 4th
CC Kevin.
On 12/09/2014 05:54 PM, Jan Kiszka wrote:
On 2014-12-04 03:24, Jike Song wrote:
Hi all,
We are pleased to announce the first release of KVMGT project. KVMGT is
the implementation of Intel GVT-g technology, a full GPU virtualization
solution. Under Intel GVT-g, a virtual GPU
CC Kevin.
On 12/09/2014 05:54 PM, Jan Kiszka wrote:
On 2014-12-04 03:24, Jike Song wrote:
Hi all,
We are pleased to announce the first release of KVMGT project. KVMGT is
the implementation of Intel GVT-g technology, a full GPU virtualization
solution. Under Intel GVT-g, a virtual GPU
On 12/05/2014 09:54 PM, Daniel Vetter wrote:
Yeah done a quick read-through of just the i915 bits too, same comment. I
guess this is just the first RFC and the redesign we've discussed about
already with xengt is in progress somewhere?
Yes, it's marching on with Xen now. The KVM implementation
CC Andy :)
On 12/05/2014 09:03 PM, Paolo Bonzini wrote:
On 05/12/2014 09:50, Gerd Hoffmann wrote:
A few comments on the kernel stuff (brief look so far, also
compile-tested only, intel gfx on my test machine is too old).
* Noticed the kernel bits don't even compile when configured as
mo
On 12/05/2014 04:50 PM, Gerd Hoffmann wrote:
A few comments on the kernel stuff (brief look so far, also
compile-tested only, intel gfx on my test machine is too old).
* Noticed the kernel bits don't even compile when configured as
module. Everything (vgt, i915, kvm) must be compiled into
phics-virtualization-xengt
The previous update can be found here:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03248.html
Appreciate your comments!
--
Thanks,
Jike
On 07/25/2014 04:31 PM, Jike Song wrote:
Hi all,
We're pleased to announce an update to Intel Graphics Virt
Hi all,
We are pleased to announce the first release of KVMGT project. KVMGT is the
implementation of Intel GVT-g technology, a full GPU virtualization solution.
Under Intel GVT-g, a virtual GPU instance is maintained for each VM, with part
of performance critical resources directly assigned.
On 10/22/2014 05:48 PM, Daniel Vetter wrote:
So on a very high level I don't understand this design. For the guest side
it's completely clear that we need a bunch of hooks over the driver to
make paravirtualization work.
But on the host side I expect the driver to be in full control of the
hardw
On 10/01/2014 12:26 AM, Tian, Kevin wrote:
From virtualization p.o.v, the ideal case is to run host i915 irq handler in
the
interrupt context, which meets all the assumption from original code. Using
tasklet or other manner still has some restriction. This is a major open we'd
like to hear more
On 10/1/2014 12:34 AM, Tian, Kevin wrote:
+void i915_vgt_record_priv(struct drm_i915_private *priv)
+{
+ dev_priv = priv;
+}
--
Suppose above can be carried in i915_start_vgt, instead of adding
a new interface?
Thanks
Kevin
Should be not? since the drm_device is not yet allocated in
i
On 09/29/2014 09:27 PM, Daniel Vetter wrote:
Well, can you still please intrigue me with why you have to change our
interrupt handling from hardirq to work item? It sounds like there's some
crucial issue of the overall design hidden in there.
Hi Daniel,
I just sent out the patch series named "A
. Whenever a virtual interrupt needs to be injected
to host i915, tasklet_schedule gets called.
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_irq.c | 35 +++
drivers/gpu/drm/i915/i915_vgt.h | 20
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/i915_drv.h | 147 +---
drivers/gpu/drm/i915/intel_uncore.c | 3 +
2 files changed, 138 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index
esume are still under cleanup;
- GPU reset is still under cleanup
We send out the framework changes in this patch set for review
at first, and meanwhile, vgt integration and cleanup are ongoing.
Jike Song (8):
drm/i915: introduce a new modparam: enable_vgt
drm/i915: introduce the ske
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/i915_drv.h | 41 ++---
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 051442e..742fe8a 100644
--- a/drivers/gpu/drm/i915
To provide Intel GPU virtualization, the host i915
driver needs to support vgt - an in-kernel device
model of Intel GPU.
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_params.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu
All of interfaces between vgt and host i915(MMIO, GTT, irq mediation)
are ready, it's safe to enable it if specified in modparam.
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/vgt/vgt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/vgt/vg
This patch convert necessary GTT read/write calls, e.g. iowrite32() and
readl() et al, to an encapsulated series: GTT_READ32, GTT_WRITE32,
GTT_READ64 and GTT_WRITE64.
This patch doesn't change the behaviors of i915 GTT access.
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/i915_
This patch introduces the skeleton of vgt, an i915 add-on
for controlling physical GPU resources and sharing among VMs.
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/Kconfig| 18 ++
drivers/gpu/drm/i915/Makefile | 4
drivers/gpu/drm/i915/i915_drv.c | 10
accessing functions, without
changing the existing i915 MMIO/GTT access behaviors.
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/i915_vgt.h | 21
drivers/gpu/drm/i915/vgt/vgt.c | 105
2 files changed, 126 insertions(+)
diff --git a/drivers
On 09/29/2014 08:20 PM, Daniel Vetter wrote:
On Mon, Sep 29, 2014 at 02:20:27PM +0800, Jike Song wrote:
On 09/15/2014 08:55 PM, Daniel Vetter wrote:
Now we tackle the functions also called from interrupt handlers.
- intel_check_page_flip is exclusively called from irq handlers, so a
plain
On 09/29/2014 08:16 PM, Chris Wilson wrote:
On Mon, Sep 29, 2014 at 07:44:56PM +0800, Jike Song wrote:
On 09/19/2014 03:25 PM, Chris Wilson wrote:
Now, given that these are simply trapped memory access, wouldn't it be
simply to have:
struct i915_virtual_gpu {
struct vgt_if *if;
On 09/19/2014 03:25 PM, Chris Wilson wrote:
Now, given that these are simply trapped memory access, wouldn't it be
simply to have:
struct i915_virtual_gpu {
struct vgt_if *if;
} vgu;
static inline bool intel_vgpu_active(struct drm_i915_private *i915) { return
i915->vgpu.if; }
then you
On 09/15/2014 08:55 PM, Daniel Vetter wrote:
Now we tackle the functions also called from interrupt handlers.
- intel_check_page_flip is exclusively called from irq handlers, so a
plain spin_lock is all we need. In i915_irq.c we have the convention
to give all such functions an _irq_handle
On 09/19/2014 04:25 PM, Chris Wilson wrote:
This should be moved to sanitize_enable_ppgtt(), probably by expanding
HAS_PPGTT(), e.g.:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 07dafa2c2d8c..b1fa13942d14 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++
On 09/19/2014 04:07 PM, Chris Wilson wrote:
On Sat, Sep 20, 2014 at 02:47:04AM +0800, Jike Song wrote:
From: Yu Zhang
Framebuffer compression is disabled when driver detects it's
running in XenGT VM, because XenGT does not provide emulations
for FBC related operations, and we do not e
Hi Chris, thanks very much for your detailed comments! I'll try
to address them as well as in your other emails.
On 09/19/2014 03:25 PM, Chris Wilson wrote:
On Sat, Sep 20, 2014 at 02:47:01AM +0800, Jike Song wrote:
From: Yu Zhang
Introduce a PV INFO structure, to facilitate the Intel
[adding cc. By mistake I set suppresscc=all in my ~/.gitconfig]
On 09/19/2014 02:59 PM, Chris Wilson wrote:
On Sat, Sep 20, 2014 at 02:47:07AM +0800, Jike Song wrote:
From: Yu Zhang
In the virtualized environment, forcewake operations are not
necessory for the driver, because mmio accesses
being accessed in the middle of VM modesetting,
e.g. compositing the framebuffer in the host side
Signed-off-by: Yu Zhang
Signed-off-by: Jike Song
Signed-off-by: Zhiyuan Lv
---
drivers/gpu/drm/i915/i915_dma.c | 8
drivers/gpu/drm/i915/i915_reg.h | 7 +++
drivers/gpu/drm
__raw_i915_write, therefore will reduce many traps and
increase the overall performance for drivers runing in the VM
with Intel GVT-g enhancement
Signed-off-by: Yu Zhang
Signed-off-by: Jike Song
Signed-off-by: Kevin Tian
---
drivers/gpu/drm/i915/i915_dma.c | 7 +--
drivers/gpu/drm/i915/i915_drv.h
igned-off-by: Yu Zhang
Signed-off-by: Jike Song
Signed-off-by: Eddie Dong
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2a5351d..3471f15 100644
--- a/drivers/gpu/drm/i915/i915_
patch also added a new callback
routine - vgpu_mm_switch() to set the PP_DIR_BASE by mmio writes.
Signed-off-by: Yu Zhang
Signed-off-by: Jike Song
---
drivers/gpu/drm/i915/i915_dma.c | 5 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++
2 files changed, 19 insertions(+)
diff
physical GTT space.
Signed-off-by: Yu Zhang
Signed-off-by: Jike Song
Signed-off-by: Zhi Wang
Signed-off-by: Eddie Dong
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 179 ++--
1 file changed, 171 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Yu Zhang
In XenGT, GPU power management is controlled by host i915
driver, so there is no need to provide virtualized GPU PM
support. In the future it might be useful to gather VM
input for freq boost, but now let's disable it simply.
Signed-off-by: Yu Zhang
Signed-off-by: Jike
ts 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, it will return true only when the driver is running in the
XenGT environment on HSW.
Signed-off-by: Yu Zhang
Signed-off-by:
From: Yu Zhang
Framebuffer compression is disabled when driver detects it's
running in XenGT VM, because XenGT does not provide emulations
for FBC related operations, and we do not expose stolen memory
to the VM.
Signed-off-by: Yu Zhang
Signed-off-by: Jike Song
Signed-off-by: Zhiyu
Intel GVT-g (previously known as XenGT), is a complete GPU
virtualization solution with mediated pass-through for 4th
generation Intel Core processors - Haswell platform. This
technology presents a virtual full-fledged GPU to each Virtual
Machine (VM). VMs can directly access performance-critical
r
On 07/29/2014 06:09 PM, Dario Faggioli wrote:
Perhaps the info is available somewhere already (in which case, sorry),
but what's the (if any) upstreaming plan/status/ETA?
I think this info could well be part of these updates. :-)
Thanks for your opinion :-)
We plan to start the upstreaming wo
Hi all,
We're pleased to announce an update to Intel Graphics Virtualization Technology
(Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution
with mediated pass-through, supported today on 4th generation Intel Core(TM)
processors with Intel Graphics processors. A virt
66 matches
Mail list logo
