Re: [Xen-devel] Building XenGT for Intel embedded board

[Wang, Hongbo]

+GVT-g mailloop

Hi Barooah,
Thanks for your interests in XenGT.
The document and git you mentioned is an old version to bring up XenGT on Intel
Apollo Lake (code name) embedded board. It's using old architecture XenGT.
After GVT-g has been upstreamed to kernel 4.10, we would like users to switch
to this new architecture GVT-g because it's upstream friendly and our latest 
features 
and patches will only apply to this version.

In order to bring up XenGT on Apollo Lake (APL), it does need minor ABL 
changes, apply some APL
SoC patches to "upstream" version XenGT, it also needs i915 drm driver changes 
in Guest
Yocto.
Can you check with your Intel account manager to get more information?


Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.w...@intel.com


> -Original Message-
> From: Zhang, Haozhong
> Sent: Thursday, August 17, 2017 3:42 PM
> To: Monisha Barooah <mbaro...@rivian.com>
> Cc: xen-devel@lists.xen.org; Wang, Hongbo <hongbo.w...@intel.com>
> Subject: Re: [Xen-devel] Building XenGT for Intel embedded board
> 
> +Hongbo Wang from Intel GPU virtualization team
> 
> On 08/10/17 22:47 +, Monisha Barooah wrote:
> > Hi Everyone,
> > I am currently exploring on bringing up XenGT for an Intel embedded
> board.
> >
> > I came across this document relating to bringing up XenGT for the
> > Sandy Bridge/Ivy Bridge/Haswell platform
> >
> https://www.intel.com/content/dam/www/public/us/en/documents/guides
> /xg
> > engt-for-ivi-solutions-dev-kit-getting-started-guide.pdf
> >
> > Our current Intel embedded board is up with an Yocto image integrated
> with the Intel BSP for the board. The board uses ABL boot loader.
> >
> > I saw in the XenGT document for the Sandy Bridge/Ivy Bridge/Haswell
> platform, that there is mention of Qemu alone and no mention of any Intel
> BSPs. Don't we require Intel BSP for dom0 kernel to work in the XenGT
> hypervisor? Or is a generic version of Intel BSP integrated with the kernel
> image link https://github.com/01org/XenGT-Preview-kernel.git.
> >
> > Also, as we have an Yocto image in the Intel board, we might have to cross
> compile the Kernel, Xen and Qemu builds as mentioned in the link above for
> our Intel embedded board using a Linaro toolchain. If not, is there a way, we
> can link this particular version of XenGT directly with our Yocto image for 
> the
> Intel board by including the meta-virtualization layer as mentioned in the 
> link
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/about/ and
> doing 'bitbake xen image minimal'?
> >
> > Please advise which is the correct route to take in this regard.
> >
> > Thanks
> > M
> >
> >
> >
> >
> __
>  CONFIDENTIALITY NOTE: This electronic message (including any
> attachments) may contain information that is privileged, confidential, and
> proprietary. If you are not the intended recipient, you are hereby notified
> that any disclosure, copying, distribution, or use of the information
> contained herein (including any reliance thereon) is strictly prohibited. If 
> you
> received this electronic message in error, please immediately reply to the
> sender that you have received this communication and destroy the material
> in its entirety, whether in electronic or hard copy format. Although Rivian
> Automotive Inc. has taken reasonable precautions to ensure no viruses are
> present in this email, Rivian accepts no responsibility for any loss or damage
> arising from the use of this email or attachments.
> 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Graphical virtualization in intel® Atom is possible?

[Wang, Hongbo]

+gvtg mailloop.

We haven't tried Atom boards to support GVT-g.
What we have verified are Intel Core platform (client machine), Intel Xeon E3 
server with embedded GPU, and
we also tried Apollo Lake (Code name) SoC board but Atom MinnowBoard can't 
support.


Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.w...@intel.com


> -Original Message-
> From: Zhang, Haozhong
> Sent: Thursday, August 17, 2017 3:44 PM
> To: Asharaf Perinchikkal <asharaf.perinchik...@quest-global.com>
> Cc: xen-devel@lists.xen.org; Anoop Babu <anoop.b...@quest-global.com>;
> Wang, Hongbo <hongbo.w...@intel.com>
> Subject: Re: [Xen-devel] Graphical virtualization in intel® Atom is possible?
> 
> +Hongbo Wang from Intel GPU virtualization team
> 
> On 08/17/17 06:36 +, Asharaf Perinchikkal wrote:
> > Hi All,
> >
> > We are trying to do graphical virtualization in intel® Atom™
> E3845(MinnowBoard Turbot Quad-Core board) using xen.
> >
> > Is it possible to do graphical virtualization in intel® Atom?
> >
> > If yes,Could you please suggest what are versions of xen and linux
> recommended to use and steps i need to follow?
> >
> > Regards
> > Asharaf P
> > ---Disclaimer-- This e-mail contains PRIVILEGED
> AND CONFIDENTIAL INFORMATION intended solely for the use of the
> addressee(s). If you are not the intended recipient, please notify the sender
> by e-mail and delete the original message. Opinions, conclusions and other
> information in this transmission that do not relate to the official business 
> of
> QuEST Global and/or its subsidiaries, shall be understood as neither given nor
> endorsed by it. Any statements made herein that are tantamount to
> contractual obligations, promises, claims or commitments shall not be
> binding on the Company unless followed by written confirmation by an
> authorized signatory of the Company.
> ---
> 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Is possible to do GPU virtualization in Intel® Atom?

[Wang, Hongbo]

Hi,

Intel GVT-g supports Intel Core platform, E3 server platform but we haven't 
tried your Atom Minnowboard.
The GPU generation delta needs additional GPU device model development work.
If you're using Skylake architecture based Atom (Apollo lake) platform, GVT-g 
can work with additional SoC patches.

BTW: GVT-g doesn't need VT-d not like other pass though devices.


Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.w...@intel.com


> -Original Message-
> From: Zhang, Haozhong
> Sent: Thursday, August 3, 2017 12:57 PM
> To: Asharaf Perinchikkal <asharaf.perinchik...@quest-global.com>
> Cc: Roger Pau Monné <roger@citrix.com>; xen-devel@lists.xen.org;
> Anoop Babu <anoop.b...@quest-global.com>; Wang, Hongbo
> <hongbo.w...@intel.com>
> Subject: Re: [Xen-devel] Is possible to do GPU virtualization in Intel® Atom?
> 
> +Hongbo from Intel GPU virtualization team
> 
> On 08/02/17 09:41 +, Asharaf Perinchikkal wrote:
> > Is possible to achieve GPU virtualization in Intel® Atom using para
> virtualization?
> > 
> > From: Roger Pau Monné [roger@citrix.com]
> > Sent: Wednesday, August 02, 2017 1:04 PM
> > To: Asharaf Perinchikkal
> > Cc: xen-devel@lists.xen.org; Anoop Babu
> > Subject: Re: [Xen-devel] Is possible to do GPU virtualization in Intel® 
> > Atom?
> >
> > On Tue, Aug 01, 2017 at 10:01:01AM +, Asharaf Perinchikkal wrote:
> > > Hi All,
> > >
> > >
> > > In Intel® Atom™ E3845(MinnowBoard Turbot Quad-Core board) has only
> support for Virtualization Technology (VT-x).
> > >
> > > No support for Intel® Virtualization Technology for Directed I/O
> > > (VT-d).
> > > [https://ark.intel.com/products/78475/Intel-Atom-Processor-E3845-2M-
> > > Cache-1_91-GHz]
> >
> > Without VT-d (IOMMU) you won't be able to passthrough any physical
> > device to a guest, so no, you won't be able to do GPU passthrough (at
> > least in a safe way).
> >
> > Roger.
> > ---Disclaimer-- This e-mail contains
> > PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the
> use of
> > the addressee(s). If you are not the intended recipient, please notify
> > the sender by e-mail and delete the original message. Opinions,
> > conclusions and other information in this transmission that do not
> > relate to the official business of QuEST Global and/or its
> > subsidiaries, shall be understood as neither given nor endorsed by it.
> > Any statements made herein that are tantamount to contractual
> > obligations, promises, claims or commitments shall not be binding on
> > the Company unless followed by written confirmation by an authorized
> > signatory of the Company.
> > --
> > -
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [Intel-gfx] [Announcement] 2016-Q4 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Wang, Hongbo]

Hi all,

We are pleased to announce another update of Intel GVT-g for Xen.

Intel GVT-g is a full GPU virtualization solution with mediated pass-through, 
starting from 4th generation Intel Core(TM) processors with Intel Graphics 
processors. A virtual GPU instance is maintained for each VM, with part of 
performance critical resources directly assigned. The capability of running 
native graphics driver inside a VM, without hypervisor intervention in 
performance critical paths, achieves a good balance among performance, feature, 
and sharing capability. Xen is currently supported on Intel Processor Graphics 
(a.k.a. XenGT).

Repositories
-Xen: https://github.com/01org/igvtg-xen (2016q4-4.6 branch)
-Kernel: https://github.com/01org/igvtg-kernel (2016q4-4.3.0 branch)
-Qemu: https://github.com/01org/igvtg-qemu (2016q4-2.3.0 branch)

This update consists of:
-Support new platform: Intel Core 7th Generation, and Intel Xen E3 v6.  
Code name is Kabylake.
-Improve stability when QoS feature is enabled
-Windows10 RedStone2 64bit support


Known issues:< QA need provide>
-   At least 2GB memory is suggested for Guest Virtual Machine (win7-32/64, 
win8.1-64, win10-64) to run most 3D workloads
-   Windows8 and later Windows fast boot is not supported, the workaround is to 
disable power S3/S4 in HVM file by adding “acpi_S3=0, acpi_S4=0”
-   Sometimes when dom0 and guest has heavy workload, i915 in dom0 will trigger 
a false-alarmed TDR. The workaround is to disable dom0 hangcheck in dom0 grub 
file by adding “i915.enable_hangcheck=0”

This is the last GVT-g community release based on old architecture design. 
After that, our next community release will switch to new code repository and 
new upstream architecture which has been upstreamed in kernel 4.10. 
Refer to the following blog for more details. 
https://01.org/igvt-g/blogs/wangbo85/2017/gvt-g-upstream-status-update-were-transition-phase
 

GVT-g project portal: https://01.org/igvt-g please subscribe mailing list: 
https://lists.01.org/mailman/listinfo/igvt-g

More information about background, architecture and others about Intel GVT-g, 
can be found at:
https://01.org/igvt-g
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-REWRITE%203RD%20v4.pdf
https://01.org/xen/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.



Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.w...@intel.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [iGVT-g] XenGT GPU virtualization

[Wang, Hongbo]

Intel XenGT has another maillist " igv...@lists.01.org" to discuss Intel GPU
virtualization questions, including XenGT and KVMGT. Feel free to subscribe.

Right now, we have two version GVT-g, "old architecture" vs "new
architecture for upstream"
Old architecture:
  - The codes are maintained off-tree, support both XenGT and KVMGT.
  - Our latest code is 2016Q3 version in Oct'16, 2016Q4 version is coming
   soon due to some open bugs.
  - 2016Q3 release blog:
   
https://01.org/igvt-g/blogs/wangbo85/2016/intel-gvt-g-iso-public-release-q32016 
  - Repo  Kernel: https://github.com/01org/igvtg-kernel 
 Xen: https://github.com/01org/igvtg-xen 
 QEMU: https://github.com/01org/igvtg-qemu 


New architecture for upstream:
  - KVMGT version with new VFIO interface have been upstreamed into
   kernel 4.10. You can see the code from kernel 4.10, or from our own 
   GVT-g repo which hosts latest code and bug fixing.
  - Repo Kernel:   https://github.com/01org/gvt-linux.git 
QEMU:  git://git.qemu.org/qemu.git 
  - XenGT code upstream is ongoing, not upstreamed. So you can't see
   those code yet. We already have a workable XenGT version for upstream,
   may share the code after interface polishing.

More details about two versions, please refer to below introduction blog:
https://01.org/igvt-g/blogs/wangbo85/2017/gvt-g-upstream-status-update-were-transition-phase
 


Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.w...@intel.com

> -Original Message-
> From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Haozhong
> Zhang
> Sent: Friday, February 24, 2017 9:43 AM
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org; 'bharat gohil' ;
> igv...@lists.01.org
> Subject: Re: [iGVT-g] [Xen-devel] XenGT GPU virtualization
> 
> Cc'ed to the mailing list of Intel graphic virtualization
> 
> [Sorry for the spam. The last cc failed as I didn't subscribe to
> igv...@lists.01.org]
> 
> On 02/23/17 12:36 +, Paul Durrant wrote:
> > Hi,
> >
> >   I’m not actually sure where the latest public release of the xengt code
> is. Perhaps someone from Intel can comment?
> >
> >   Otherwise, if you grab the source ISOs from xenserver.org you can look
> in the SRPM for xengt. The xengt kernel module is responsible for auditing
> the servicing the GPU commands from guests.
> >
> >   Cheers,
> >
> >   Paul
> >
> >
> > From: bharat gohil [mailto:ghl.b...@gmail.com]
> > Sent: 23 February 2017 12:30
> > To: Paul Durrant 
> > Cc: Anshul Makkar ;
> xen-de...@lists.xenproject.org
> > Subject: Re: [Xen-devel] XenGT GPU virtualization
> >
> > Thanks paul and anshul
> > Can you guys point out source code which is audit the GPU command?
> >
> > Thanks
> > Bharat
> >
> > On Mon, Feb 20, 2017 at 9:01 PM, Paul Durrant
> > wrote:
> > No, that’s not correct. The GPU commands are whitelisted and only the
> commands that can be audited are handled.
> >
> >   Paul
> >
> > From: Xen-devel
> [mailto:xen-devel-boun...@lists.xen.org en.org>] On Behalf Of anshul makkar
> > Sent: 20 February 2017 15:16
> > To: bharat gohil >;
> xen-de...@lists.xenproject.org
> > Subject: Re: [Xen-devel] XenGT GPU virtualization
> >
> >
> >
> >
> > On 18/01/17 13:21, bharat gohil wrote:
> > Hello
> >
> > I am new to GPU and GPU virtualization and found that xen support intel
> GPU virtualization using XenGT.
> > I want to know,
> > 1) What are the critical GPU command pass from xen to Dom0?
> > 2) How the Dom0 mediator or xen validate the GPU command which is
> passed from domU GPU driver?
> > 3) If one of the domU guest send bad(malicious) command to GPU which
> led GPU to bad state. Can Dom0 mediator or xen prevents this kind of
> scenario?
> > As far as I know, there is know mediation to check for the commands. Xen
> does audit the target address space, but not GPU commands.
> >
> > --
> > Regards,
> > Bharat Gohil
> >
> >
> >
> >
> > ___
> >
> > Xen-devel mailing list
> >
> > Xen-devel@lists.xen.org
> >
> > https://lists.xen.org/xen-devel
> >
> >
> >
> >
> > --
> > Regards,
> > Bharat Gohil
> > Sr.Software Engineer
> > bharat.go...@harman.com
> > +919427054633
> 
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
> 
> ___
> iGVT-g mailing list
> igv...@lists.01.org
> https://lists.01.org/mailman/listinfo/igvt-g
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] No joy with Xen 4.5 based iGVT-G.

[Wang, Hongbo]

Follow with Kevin's comment, our latest XenGT Q3'15 release is based on Xen 
4.5, qemu 1.3, kernel 3.18.
You may want to try and make comparison.
The latest release notes: 
https://01.org/igvt-g/blogs/wangbo85/2015/intel-gvt-g-xengt-public-release-q32015
 

BTW: we have quarterly release for XenGT.  Please follow our website: 
https://01.org/group/2230/blogs 

Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.w...@intel.com


-Original Message-
From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Tian, Kevin
Sent: Thursday, December 3, 2015 2:29 PM
To: g...@enjellic.com; xen-us...@lists.xen.org; xen-devel@lists.xen.org
Cc: White, Michael L ; igv...@lists.01.org
Subject: Re: [iGVT-g] No joy with Xen 4.5 based iGVT-G.

> From: Dr. Greg Wettstein [mailto:g...@wind.enjellic.com]
> Sent: Monday, November 30, 2015 2:05 AM
> 
> Hi, I hope everyone has had an enjoyable weekend, particularly for 
> those who were enjoying the Thanksgiving holiday.
> 
> We've been following the i915 graphics virtualization project for some 
> time.  We have been working on the engineering behind some solutions 
> which we hope to base on this technology.

Thanks for your interest in our technology. Can you share your usage scenarios 
on it?

> 
> We had ported the Xen 4.3 based version of the iGVT-G support into 4.4 
> using the Q1-2015 xen/qemu/kernel releases.  Most of our development 
> has been on this platform release and have found it extremely stable 
> through hundreds of dom0 reboots and VM starts.

Good to know that. :-)

> 
> For a 'Thanksgiving weekend project' I took on porting our 4.4 version 
> into 4.5 and slogged through all the issues around the new hypervisor 
> ioreq server model.  I was just starting to validate functionality 
> when I discovered, midway through the weekend, the 'official' 4.5 
> release based on the new server architecture... :-)(.
> 
> All through the work on the port it felt like we were driving a square 
> peg into a round hole given how the new ioreq server architecture was 
> being done.  It was obvious this was the 'correct' way to do the 
> virtual machine I/O region mapping but wanted to get something we were 
> familiar with working.
> 
> About the time I started testing the port our Golden Retriever vomited 
> on one of my keyboards, which I took as the final sign that our code 
> was an ugly hack so I decided to bring up the official 4.5 release for 
> testing :-)
> 
> Unfortunately we haven't found the success with the 4.5 release that 
> we experienced with the 4.4 'old I/O model' code.  On identical 
> hardware we see very intermittent success on getting dom0 booted to 
> operational status.  The failures occur when the i915 modeset is 
> executed in dom0, which of course corresponds to the initialization of 
> the VGT instance.
> 
> The failure occurs both with a hypervisor built from the Github branch 
> of the 4.5 code as well as with a hypervisor built from 4.5.2 sources 
> patched with VGT support.  I'm including below the console messages of 
> a representative boot failure.
> 
> I did note the 'Unclaimed register detected' error and will get 
> i915.mmio_debug output from that tonight but as I noted the same 
> hardware functions flawlessly on the 4.4 based implementation.
> 
> On the rare boots which are successful we get the following message 
> out of the hypervisor when a VGT based HVM is started:
> 
> (XEN) traps.c:668:d1v0 Bad GMFN 800080 (MFN ) to 
> MSR 4000
> 
> Which results in a segmentation fault of the VGT QEMU instance.
> 
> This is on a Haswell based system.  We have testing scheduled for a 
> Broadwell platform but since support is less advanced on the latter 
> platform we didn't want to add another variable to the situation.
> 
> This is extremely useful and powerful technology and we want to 
> support its development so we would be happy to dig into whatever 
> additional debugging would be useful.  We have pretty solid 
> engineering skills across the range of technologies in play but we 
> would certainly not claim considerable expertise on the i915 hardware 
> itself.
> 
> I've copied a smattering of the involved Intel folks on this as well.
> One of our concerns is whether or not this is an 'experiment' or 
> something Intel plans on supporting in the long term.  We have obvious 
> concerns about basing solutions on technology if the underlying 
> hardware should change in a manner that we could not support the 
> solution ourselves and if Intel were to abandon the concept.

Intel will support this technology in the long term. This project starts from 
HSW, now stable on BDW, preliminary SKL support comes in Q4, etc. Yes, it will 
continue.

> 
> Have a good day.
> 

If I read above correctly, you are using 2015-Q1 release and doing your own 
porting from 4.3->4.4->4.5... Why not trying the latest
2015-Q3 release which is already based on 4.5 w/ new