from:"Xu, Terrence"

Re: [Intel-gfx] [PATCH v5 00/10] Enhance vfio PCI hot reset for vfio cdev device

2023-05-17 Thread Xu, Terrence

> -Original Message-
> From: Liu, Yi L 
> Subject: [PATCH v5 00/10] Enhance vfio PCI hot reset for vfio cdev device
> 
> VFIO_DEVICE_PCI_HOT_RESET requires user to pass an array of group fds to
> prove that it owns all devices affected by resetting the calling device. While
> for cdev devices, user can use an iommufd-based ownership checking model
> and invoke VFIO_DEVICE_PCI_HOT_RESET with a zero-length fd array.
> 
> This series first creates iommufd_access for noiommu devices to fill the gap
> for adding iommufd-based ownership checking model, then extends
> VFIO_DEVICE_GET_PCI_HOT_RESET_INFO to check ownership and return
> the check result and the devid of affected devices to user. In the end,
> extends the VFIO_DEVICE_PCI_HOT_RESET to accept zero-length fd array for
> hot-reset with cdev devices.
> 
> The new hot reset method and updated _INFO ioctl are tested with the
> below qemu:
> 
> https://github.com/yiliu1765/qemu/tree/iommufd_rfcv4.mig.reset.v4_var3
> (requires to test with the cdev kernel)
> 
> Change log:
> 
> v5:
>  - Drop patch 01 of v4 (Alex)
>  - Create noiommu_access for noiommu devices (Jason)
>  - Reserve all negative iommufd IDs, hence VFIO can encode negative
>values (Jason)
>  - Make vfio_iommufd_physical_devid() return -EINVAL if it's not called
>with a physical device or a noiommu device.
>  - Add vfio_find_device_in_devset() in vfio_main.c (Alex)
>  - Add iommufd_ctx_has_group() to replace
> vfio_devset_iommufd_has_group().
>Reason: vfio_devset_iommufd_has_group() only loops the devices within
>the given devset to check the iommufd an iommu_group, but an
> iommu_group
>can span into multiple devsets. So if failed to find the group in a
>devset doesn't mean the group is not owned by the iommufd. So here
> either
>needs to search all the devsets or add an iommufd API to check it. It
>appears an iommufd API makes more sense.
>  - Adopt suggestions from Alex on patch 08 and 09 of v4, refine the hot-reset
>uapi description and minor tweaks
>  - Use bitfields for bool members (Alex)
> 
> v4: https://lore.kernel.org/kvm/20230426145419.450922-1-yi.l@intel.com/
>  - Rename the patch series subject
>  - Patch 01 is moved from the cdev series
>  - Patch 02, 06 are new per review comments in v3
>  - Patch 03/04/05/07/08/09 are from v3 with updates
> 
> v3: https://lore.kernel.org/kvm/20230401144429.88673-1-yi.l@intel.com/
>  - Remove the new _INFO ioctl of v2, extend the existing _INFO ioctl to
>report devid (Alex)
>  - Add r-b from Jason
>  - Add t-b from Terrence Xu and Yanting Jiang (mainly regression test)
> 
> v2: https://lore.kernel.org/kvm/20230327093458.44939-1-yi.l@intel.com/
>  - Split the patch 03 of v1 to be 03, 04 and 05 of v2 (Jaon)
>  - Add r-b from Kevin and Jason
>  - Add patch 10 to introduce a new _INFO ioctl for the usage of device
>fd passing usage in cdev path (Jason, Alex)
> 
> v1: https://lore.kernel.org/kvm/20230316124156.12064-1-yi.l@intel.com/
> 
> Regards,
>   Yi Liu
> 
> Yi Liu (10):
>   vfio-iommufd: Create iommufd_access for noiommu devices
>   vfio/pci: Update comment around group_fd get in
> vfio_pci_ioctl_pci_hot_reset()
>   vfio/pci: Move the existing hot reset logic to be a helper
>   vfio: Mark cdev usage in vfio_device
>   iommufd: Reserve all negative IDs in the iommufd xarray
>   vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for
> vfio_device
>   vfio: Add helper to search vfio_device in a dev_set
>   iommufd: Add iommufd_ctx_has_group()
>   vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device
> cdev
>   vfio/pci: Allow passing zero-length fd array in
> VFIO_DEVICE_PCI_HOT_RESET
> 
>  drivers/iommu/iommufd/device.c   |  53 +
>  drivers/iommu/iommufd/main.c |   2 +-
>  drivers/vfio/iommufd.c   |  63 ++-
>  drivers/vfio/pci/vfio_pci_core.c | 184 ---
>  drivers/vfio/vfio_main.c |  15 +++
>  include/linux/iommufd.h  |  14 +++
>  include/linux/vfio.h |  23 
>  include/uapi/linux/vfio.h|  60 +-
>  8 files changed, 368 insertions(+), 46 deletions(-)
> 
> --
> 2.34.1

The new uapi works fine.
Tested GVT-g / GVT-d VFIO legacy mode / compat mode / cdev mode, including 
negative tests. No regression be introduced.  

Tested-by: Terrence Xu

Re: [Intel-gfx] [PATCH v11 00/23] Add vfio_device cdev for iommufd support

2023-05-17 Thread Xu, Terrence

> -Original Message-
> From: Liu, Yi L 
> Subject: [PATCH v11 00/23] Add vfio_device cdev for iommufd support
> 
> Existing VFIO provides group-centric user APIs for userspace. Userspace
> opens the /dev/vfio/$group_id first before getting device fd and hence
> getting access to device. This is not the desired model for iommufd. Per the
> conclusion of community discussion[1], iommufd provides device-centric
> kAPIs and requires its consumer (like VFIO) to be device-centric user APIs.
> Such user APIs are used to associate device with iommufd and also the I/O
> address spaces managed by the iommufd.
> 
> This series first introduces a per device file structure to be prepared for
> further enhancement and refactors the kvm-vfio code to be prepared for
> accepting device file from userspace. After this, adds a mechanism for
> blocking device access before iommufd bind. Then refactors the vfio to be
> able to handle cdev path (e.g. iommufd binding, no-iommufd, [de]attach
> ioas).
> This refactor includes making the device_open exclusive between the group
> and the cdev path, only allow single device open in cdev path; vfio-iommufd
> code is also refactored to support cdev. e.g. split the vfio_iommufd_bind()
> into two steps. Eventually, adds the cdev support for vfio device and the new
> ioctls, then makes group infrastructure optional as it is not needed when vfio
> device cdev is compiled.
> 
> This series is based on some preparation works done to vfio emulated
> devices[2] and vfio pci hot reset enhancements[3].
> 
> This series is a prerequisite for iommu nesting for vfio device[4] [5].
> 
> The complete code can be found in below branch, simple tests done to the
> legacy group path and the cdev path. Draft QEMU branch can be found at[6]
> However, the noiommu mode test is only done with some hacks in kernel
> and qemu to check if qemu can boot with noiommu devices.
> 
> https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v11
> (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y)
> 
> base-commit: b8b967d5ec691bddb883ab2abbfb8d632c97052e
> 
> [1]
> https://lore.kernel.org/kvm/BN9PR11MB5433B1E4AE5B0480369F97178C189
> @BN9PR11MB5433.namprd11.prod.outlook.com/
> [2] https://lore.kernel.org/kvm/20230327093351.44505-1-yi.l@intel.com/ -
> merged [3] https://lore.kernel.org/kvm/20230513132136.15021-1-
> yi.l@intel.com/
> [4] https://lore.kernel.org/linux-iommu/20230511143844.22693-1-
> yi.l@intel.com/
> [5] https://lore.kernel.org/linux-iommu/20230511145110.27707-1-
> yi.l@intel.com/#t
> [6]
> https://github.com/yiliu1765/qemu/tree/iommufd_rfcv4.mig.reset.v4_var3
> 
> Change log:
> 
> v11:
>  - Add back the noiommu determination at vfio device registration patch and
>put it prior to compiling vfio_group code optionally as compiling 
> vfio_group
>optionaly is the major reason for it.
>  - Fix a typo related to SPAPR (Cédric Le Goater)
>  - Add t-b from Shameerali Kolothum Thodi, tested on HiSilicon D06(ARM64)
> platform
>with a NIC pass-through
> 
> v10: https://lore.kernel.org/kvm/20230426150321.454465-1-
> yi.l@intel.com/
>  - Drop patch 03 of v9 as vfio_file_is_group() is still needed by pci hot 
> reset
> path
>  - Drop 11 of v9 per the change of noiommu support
>  - Move patch 18 of v9 to hot-reset series [3]
>  - vfio_file_has_device_access() is dropped as no usage now (hot-reset does
> not accept
>device fd, hence no need for this helper)
>  - Minor change to patch 02, mainly make it back to patch v2 of v6 which is
> before
>splitting hot-reset series
>  - Minor change in 10 and 11 due to rebase
>  - Functional changes in patch 19, 20 and 21 per the latest noiommu support
>policy. noiommu device can be bound to valid iommufd now, this is
> different
>from the prior policy in which noiommu device is not allowed to be bound
> to
>valid iommufd. So may pay more attention on the three patches, previous
> r-b
>and t-b are dropped for these three patches.
> 
> v9: https://lore.kernel.org/kvm/20230401151833.124749-1-yi.l@intel.com/
>  - Use smp_load_acquire() in vfio_file_has_device_access() for df-
> >access_granted (Alex)
>  - Fix lock init in patch 16 of v8 (Jon Pan-Doh)
>  - Split patch 20 of v8 (Alex)
>  - Refine noiommu logic in BIND_IOMMUFD (Alex)
>  - Remove dev_cookie in BIND_IOMMUFD ioctl (Alex, Jason)
>  - Remove static_assert in ATTACH/DETACH ioctl handling (Alex)
>  - Remove device->ops->bind_iommufd presence check in
> BIND_IOMMUFD/ATTACH/DETACH handling (Alex)
>  - Remove VFIO dependecny for VFIO_CONTAINER as VFIO_GROUP should
> imply it (Alex)
>  - Improve the documentation per suggestions from Alex on patch 24 of v8
> (Alex)
>  - Remove WARN_ON(df->group) in vfio_device_group_uses_container() of
> patch 11
>  - Add r-b from Kevin to patch 18/19 of v8
>  - Add r-b from Jason to patch 03/10/11 of v8
>  - Add t-b from Yanting Jiang and Nicolin Chen
> 
> v8: https://lore.kernel.org/kvm/20230327094047.47215-1-yi.l@intel.co

Re: [Intel-gfx] [PATCH v2 00/10] Introduce new methods for verifying ownership in vfio PCI hot reset

2023-04-01 Thread Xu, Terrence



> -Original Message-
> From: intel-gvt-dev  On
> Behalf Of Alex Williamson
> Sent: Saturday, April 1, 2023 1:50 AM
> 
> On Fri, 31 Mar 2023 17:27:27 +0000
> "Xu, Terrence"  wrote:
> 
> > > -Original Message-
> > > From: Liu, Yi L 
> > > Sent: Monday, March 27, 2023 5:35 PM
> > >
> > > VFIO_DEVICE_PCI_HOT_RESET requires user to pass an array of group
> > > fds to prove that it owns all devices affected by resetting the
> > > calling device. This series introduces several extensions to allow
> > > the ownership check better aligned with iommufd and coming vfio device
> cdev support.
> > >
> > > First, resetting an unopened device is always safe given nobody is
> > > using it. So relax the check to allow such devices not covered by
> > > group fd array. [1]
> > >
> > > When iommufd is used we can simply verify that all affected devices
> > > are bound to a same iommufd then no need for the user to provide
> > > extra fd information. This is enabled by the user passing a
> > > zero-length fd array and moving forward this should be the preferred
> > > way for hot reset. [2]
> > >
> > > However the iommufd method has difficulty working with noiommu
> > > devices since those devices don't have a valid iommufd, unless the
> > > noiommu device is in a singleton dev_set hence no ownership check is
> > > required. [3]
> > >
> > > For noiommu backward compatibility a 3rd method is introduced by
> > > allowing the user to pass an array of device fds to prove ownership.
> > > [4]
> > >
> > > As suggested by Jason [5], we have this series to introduce the
> > > above stuffs to the vfio PCI hot reset. Per the dicussion in [6],
> > > this series also adds a new _INFO ioctl to get hot reset scope for given
> device.
> > >
> > > [1] https://lore.kernel.org/kvm/y%2fdobs6gdskxn...@nvidia.com/
> > > [2] https://lore.kernel.org/kvm/y%2fzooclu8nxy2...@nvidia.com/#t
> > > [3] https://lore.kernel.org/kvm/zacx+np%2fiy7yg...@nvidia.com/
> > > [4]
> > >
> https://lore.kernel.org/kvm/DS0PR11MB7529BE88460582BD599DC1F7C3B19
> > > @DS0PR11MB7529.namprd11.prod.outlook.com/#t
> > > [5] https://lore.kernel.org/kvm/zacvzvhkt9qhc...@nvidia.com/
> > > [6] https://lore.kernel.org/kvm/zboygnq60edpv...@nvidia.com/
> > >
> > > Change log:
> > >
> > > v2:
> > >  - Split the patch 03 of v1 to be 03, 04 and 05 of v2 (Jaon)
> > >  - Add r-b from Kevin and Jason
> > >  - Add patch 10 to introduce a new _INFO ioctl for the usage of device
> > >fd passing usage in cdev path (Jason, Alex)
> > >
> > > v1:
> > > https://lore.kernel.org/kvm/20230316124156.12064-1-yi.l@intel.co
> > > m/
> > >
> > > Regards,
> > >   Yi Liu
> > >
> > > Yi Liu (10):
> > >   vfio/pci: Update comment around group_fd get in
> > > vfio_pci_ioctl_pci_hot_reset()
> > >   vfio/pci: Only check ownership of opened devices in hot reset
> > >   vfio/pci: Move the existing hot reset logic to be a helper
> > >   vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for
> > > vfio_device
> > >   vfio/pci: Allow passing zero-length fd array in
> > > VFIO_DEVICE_PCI_HOT_RESET
> > >   vfio: Refine vfio file kAPIs for vfio PCI hot reset
> > >   vfio: Accpet device file from vfio PCI hot reset path
> > >   vfio/pci: Renaming for accepting device fd in hot reset path
> > >   vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl
> > >   vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
> > >
> > >  drivers/iommu/iommufd/device.c   |  12 ++
> > >  drivers/vfio/group.c |  32 ++--
> > >  drivers/vfio/iommufd.c   |  16 ++
> > >  drivers/vfio/pci/vfio_pci_core.c | 244 
> ---
> > >  drivers/vfio/vfio.h  |   2 +
> > >  drivers/vfio/vfio_main.c |  44 ++
> > >  include/linux/iommufd.h  |   3 +
> > >  include/linux/vfio.h |  14 ++
> > >  include/uapi/linux/vfio.h|  65 +++-
> > >  9 files changed, 364 insertions(+), 68 deletions(-)
> > >
> > > --
> > > 2.34.1
> >
> > Verified this series by "Intel GVT-g GPU device mediated passthrough".
> > Passed VFIO legacy mode / compat mode / cdev mode basic functionality
> and GPU force reset test.
> >
> > Tested-by: Terrence Xu 
> 
> Seems like only this "GPU force reset test" is relevant to the new
> functionality of this series, GVT-g does not and has no reason to support the
> HOT_RESET ioctls used here.  Can you provide more details of the force-reset
> test?  What userspace driver is being used?  Thanks,
> 
> Alex
Hi Alex, about the "GPU force reset test", I used the "i915_hangman" test from 
intel-gpu-tools, it is for GPU force hang / reset. 
It is an important regression test scenario for this patch series. 
To test the HOT_RESET ioctls itself, need to wait the corresponding Qemu 
changes from Yi.

Re: [Intel-gfx] [PATCH v2 00/10] Introduce new methods for verifying ownership in vfio PCI hot reset

2023-03-31 Thread Xu, Terrence



> -Original Message-
> From: Liu, Yi L 
> Sent: Monday, March 27, 2023 5:35 PM
> 
> VFIO_DEVICE_PCI_HOT_RESET requires user to pass an array of group fds to
> prove that it owns all devices affected by resetting the calling device. This
> series introduces several extensions to allow the ownership check better
> aligned with iommufd and coming vfio device cdev support.
> 
> First, resetting an unopened device is always safe given nobody is using it. 
> So
> relax the check to allow such devices not covered by group fd array. [1]
> 
> When iommufd is used we can simply verify that all affected devices are
> bound to a same iommufd then no need for the user to provide extra fd
> information. This is enabled by the user passing a zero-length fd array and
> moving forward this should be the preferred way for hot reset. [2]
> 
> However the iommufd method has difficulty working with noiommu devices
> since those devices don't have a valid iommufd, unless the noiommu device
> is in a singleton dev_set hence no ownership check is required. [3]
> 
> For noiommu backward compatibility a 3rd method is introduced by allowing
> the user to pass an array of device fds to prove ownership. [4]
> 
> As suggested by Jason [5], we have this series to introduce the above stuffs
> to the vfio PCI hot reset. Per the dicussion in [6], this series also adds a 
> new
> _INFO ioctl to get hot reset scope for given device.
> 
> [1] https://lore.kernel.org/kvm/y%2fdobs6gdskxn...@nvidia.com/
> [2] https://lore.kernel.org/kvm/y%2fzooclu8nxy2...@nvidia.com/#t
> [3] https://lore.kernel.org/kvm/zacx+np%2fiy7yg...@nvidia.com/
> [4]
> https://lore.kernel.org/kvm/DS0PR11MB7529BE88460582BD599DC1F7C3B19
> @DS0PR11MB7529.namprd11.prod.outlook.com/#t
> [5] https://lore.kernel.org/kvm/zacvzvhkt9qhc...@nvidia.com/
> [6] https://lore.kernel.org/kvm/zboygnq60edpv...@nvidia.com/
> 
> Change log:
> 
> v2:
>  - Split the patch 03 of v1 to be 03, 04 and 05 of v2 (Jaon)
>  - Add r-b from Kevin and Jason
>  - Add patch 10 to introduce a new _INFO ioctl for the usage of device
>fd passing usage in cdev path (Jason, Alex)
> 
> v1: https://lore.kernel.org/kvm/20230316124156.12064-1-yi.l@intel.com/
> 
> Regards,
>   Yi Liu
> 
> Yi Liu (10):
>   vfio/pci: Update comment around group_fd get in
> vfio_pci_ioctl_pci_hot_reset()
>   vfio/pci: Only check ownership of opened devices in hot reset
>   vfio/pci: Move the existing hot reset logic to be a helper
>   vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for
> vfio_device
>   vfio/pci: Allow passing zero-length fd array in
> VFIO_DEVICE_PCI_HOT_RESET
>   vfio: Refine vfio file kAPIs for vfio PCI hot reset
>   vfio: Accpet device file from vfio PCI hot reset path
>   vfio/pci: Renaming for accepting device fd in hot reset path
>   vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl
>   vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
> 
>  drivers/iommu/iommufd/device.c   |  12 ++
>  drivers/vfio/group.c |  32 ++--
>  drivers/vfio/iommufd.c   |  16 ++
>  drivers/vfio/pci/vfio_pci_core.c | 244 ---
>  drivers/vfio/vfio.h  |   2 +
>  drivers/vfio/vfio_main.c |  44 ++
>  include/linux/iommufd.h  |   3 +
>  include/linux/vfio.h |  14 ++
>  include/uapi/linux/vfio.h|  65 +++-
>  9 files changed, 364 insertions(+), 68 deletions(-)
> 
> --
> 2.34.1

Verified this series by "Intel GVT-g GPU device mediated passthrough".
Passed VFIO legacy mode / compat mode / cdev mode basic functionality and GPU 
force reset test.

Tested-by: Terrence Xu

Re: [Intel-gfx] [PATCH v7 00/22] Add vfio_device cdev for iommufd support

2023-03-17 Thread Xu, Terrence



> -Original Message-
> From: Liu, Yi L 
> Subject: [PATCH v7 00/22] Add vfio_device cdev for iommufd support
> 
> Existing VFIO provides group-centric user APIs for userspace. Userspace
> opens the /dev/vfio/$group_id first before getting device fd and hence
> getting access to device. This is not the desired model for iommufd. Per the
> conclusion of community discussion[1], iommufd provides device-centric
> kAPIs and requires its consumer (like VFIO) to be device-centric user APIs.
> Such user APIs are used to associate device with iommufd and also the I/O
> address spaces managed by the iommufd.
> 
> This series first introduces a per device file structure to be prepared for
> further enhancement and refactors the kvm-vfio code to be prepared for
> accepting device file from userspace. Afte this, adds a mechanism for
> blocking device access before iommufd bind. Then refactors the vfio to be
> able to handle cdev path (e.g. iommufd binding, no-iommufd, [de]attach
> ioas).
> This refactor includes making the device_open exclusive between group and
> cdev path, only allow single device open in cdev path; vfio-iommufd code is
> also refactored to support cdev. e.g. split the vfio_iommufd_bind() into two
> steps. Eventually, adds the cdev support for vfio device and the new ioctls,
> then makes group infrastructure optional as it is not needed when vfio
> device cdev is compiled.
> 
> This series is based on some preparation works done to vfio emulated
> devices[2] and vfio pci hot reset enhancements[3].
> 
> This series is a prerequisite for iommu nesting for vfio device[4] [5].
> 
> The complete code can be found in below branch, simple tests done to the
> legacy group path and the cdev path. Draft QEMU branch can be found at[6]
> 
> https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v7
> (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y)
> 
> base-commit: d28283a0c30d2f3c82d78fbe27f258671b6dc535
> 
> [1]
> https://lore.kernel.org/kvm/BN9PR11MB5433B1E4AE5B0480369F97178C189
> @BN9PR11MB5433.namprd11.prod.outlook.com/
> [2] https://lore.kernel.org/kvm/20230316121526.5644-1-yi.l@intel.com/
> [3] https://lore.kernel.org/kvm/20230316124156.12064-1-yi.l@intel.com/
> [4] https://lore.kernel.org/linux-iommu/20230309080910.607396-1-
> yi.l@intel.com/
> [5] https://lore.kernel.org/linux-iommu/20230309082207.612346-1-
> yi.l@intel.com/
> [6] https://github.com/yiliu1765/qemu/tree/iommufd_rfcv3 (it is based on
> Eric's
> QEMU iommufd rfcv3
> (https://lore.kernel.org/kvm/20230131205305.2726330-1-
> eric.au...@redhat.com/)
> plus commits to align with vfio_device_cdev v7)
> 
> Change log:
> 
> v7:
>  - Split the vfio-pci hot reset changes to be separate patch series (Jason,
> Kevin)
>  - More polish on no-iommufd support (patch 11 - 13) in cdev path (Kevin)
>  - iommufd_access_detach() in patch 16 is added by Nic for emulated devices
> (Kevin, Jason)
> 
> v6: https://lore.kernel.org/kvm/20230308132903.465159-1-
> yi.l@intel.com/#t
>  - Add r-b from Jason on patch 01 - 08 and 13 in v5
>  - Based on the prerequisite mini-series which makes vfio emulated devices
>be prepared to cdev (Jason)
>  - Add the approach to pass a set of device fds to do hot reset ownership
>check, while the zero-length array approach is also kept. (Jason, Kevin, 
> Alex)
>  - Drop patch 10 of v5, it is reworked by patch 13 and 17 in v6 (Jason)
>  - Store vfio_group pointer in vfio_device_file to check if user is using
>legacy vfio container (Jason)
>  - Drop the is_cdev_device flag (introduced in patch 14 of v5) as the group
>pointer stored in vfio_device_file can cover it.
>  - Add iommu_group check in the cdev no-iommu path patch 24 (Kevin)
>  - Add t-b from Terrence, Nicolin and Matthew (thanks for the help, some
> patches
>are new in this version, so I just added t-b to the patches that are also
>in v5 and no big change, for others would add in this version).
> 
> v5: https://lore.kernel.org/kvm/2023022735.61728-1-yi.l@intel.com/
>  - Add r-b from Kevin on patch 08, 13, 14, 15 and 17.
>  - Rename patch 02 to limit the change for KVM facing kAPIs. The vfio pci
>hot reset path only accepts group file until patch 09. (Kevin)
>  - Update comment around smp_load_acquire(&df->access_granted) (Yan)
>  - Adopt Jason's suggestion on the vfio pci hot reset path, passing 
> zero-length
>fd array to indicate using bound iommufd_ctx as ownership check. (Jason,
> Kevin)
>  - Direct read df->access_granted value in vfio_device_cdev_close() (Kevin,
> Yan, Jason)
>  - Wrap the iommufd get/put into a helper to refine the error path of
>vfio_device_ioctl_bind_iommufd(). (Yan)
> 
> v4: https://lore.kernel.org/kvm/20230221034812.138051-1-yi.l@intel.com/
>  - Add r-b from Kevin on patch 09/10
>  - Add a line in devices/vfio.rst to emphasize user should add group/device to
>KVM prior to invoke open_device op which may be called in the
> VFIO_GROUP_GET_DEVICE_FD
>o

Re: [Intel-gfx] [PATCH v2 0/5] vfio: Make emulated devices prepared for vfio device cdev

2023-03-17 Thread Xu, Terrence



> -Original Message-
> From: Liu, Yi L 
> Sent: Thursday, March 16, 2023 8:15 PM
> 
> The .bind_iommufd op of vfio emulated devices are either empty or does
> nothing. This is different with the vfio physical devices, to add vfio device
> cdev, need to make them act the same.
> 
> This series first makes the .bind_iommufd op of vfio emulated devices to
> create iommufd_access, this introduces a new iommufd API. Then let the
> driver that does not provide .bind_iommufd op to use the vfio emulated
> iommufd op set. This makes all vfio device drivers have consistent iommufd
> operations, which is good for adding new device uAPIs in the device cdev
> series.
> 
> Change log:
> 
> v2:
>  - Add r-b from Kevin and Jason
>  - Refine patch 01 per comments from Jason and Kevin
> 
> v1: https://lore.kernel.org/kvm/20230308131340.459224-1-yi.l@intel.com/
> 
> Thanks,
>   Yi Liu
> 
> Nicolin Chen (1):
>   iommufd: Create access in vfio_iommufd_emulated_bind()
> 
> Yi Liu (4):
>   vfio-iommufd: No need to record iommufd_ctx in vfio_device
>   vfio-iommufd: Make vfio_iommufd_emulated_bind() return
> iommufd_access
> ID
>   vfio/mdev: Uses the vfio emulated iommufd ops set in the mdev sample
> drivers
>   vfio: Check the presence for iommufd callbacks in
> __vfio_register_dev()
> 
>  drivers/iommu/iommufd/device.c   | 57 
>  drivers/iommu/iommufd/selftest.c |  8 +++--
>  drivers/vfio/iommufd.c   | 39 +++---
>  drivers/vfio/vfio_main.c |  5 +--
>  include/linux/iommufd.h  |  5 +--
>  include/linux/vfio.h |  1 -
>  samples/vfio-mdev/mbochs.c   |  3 ++
>  samples/vfio-mdev/mdpy.c |  3 ++
>  samples/vfio-mdev/mtty.c |  3 ++
>  9 files changed, 76 insertions(+), 48 deletions(-)
> 
> --
> 2.34.1
Verified this series by test the vfio-mdev with mtty emulated device, it passed 
VFIO legacy mode / compat mode / cdev mode, including negative tests.

Tested-by: Terrence Xu

Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support

2023-02-28 Thread Xu, Terrence

> From: Liu, Yi L 
> Sent: Tuesday, February 28, 2023 11:03 AM
> > From: Jason Gunthorpe 
> > Sent: Tuesday, February 28, 2023 3:21 AM
> >
> > On Mon, Feb 27, 2023 at 03:11:16AM -0800, Yi Liu wrote:
> > > Existing VFIO provides group-centric user APIs for userspace.
> > > Userspace opens the /dev/vfio/$group_id first before getting device
> > > fd and hence getting access to device. This is not the desired model
> > > for iommufd. Per the conclusion of community discussion[1], iommufd
> > > provides device-
> > centric
> > > kAPIs and requires its consumer (like VFIO) to be device-centric
> > > user APIs. Such user APIs are used to associate device with iommufd
> > > and also the I/O address spaces managed by the iommufd.
> > >
> > > This series first introduces a per device file structure to be
> > > prepared for further enhancement and refactors the kvm-vfio code to
> > > be prepared for accepting device file from userspace. Then refactors
> > > the vfio to be able to handle iommufd binding. This refactor
> > > includes the mechanism of blocking device access before iommufd
> > > bind, making the device_open
> > exclusive.
> > > between the group path and the cdev path. Eventually, adds the cdev
> > support
> > > for vfio device, and makes group infrastructure optional as it is
> > > not needed when vfio device cdev is compiled.
> > >
> > > This is also a prerequisite for iommu nesting for vfio device[2].
> > >
> > > The complete code can be found in below branch, simple test done
> > > with
> > the
> > > legacy group path and the cdev path. Draft QEMU branch can be found
> > at[3]
> > >
> > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v5
> > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y)
> > >
> > > base-commit: 63777bd2daa3625da6eada88bd9081f047664dad
> >
> > This needs to be rebased onto a clean v6.3-rc1 when it comes out
> 
> Yes, I'll send rebase and send one more version when v6.3-rc1 comes. Here
> just try to be near to the vfio code in Alex's next branch.
> 
> Regards,
> Yi Liu

Verified this series by "Intel GVT-g GPU device mediated passthrough" and 
"Intel GVT-d GPU device direct passthrough" technologies.
Both passed VFIO legacy mode / compat mode / cdev mode, including negative 
tests.

Tested-by: Terrence Xu

Re: [Intel-gfx] [PATCH v4 00/10] cover-letter: Update vfio_pin/unpin_pages API

2022-07-25 Thread Xu, Terrence

> -Original Message-
> From: intel-gvt-dev  On
> Behalf Of Nicolin Chen
> 
> This is a preparatory series for IOMMUFD v2 patches. It prepares for
> replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
> with IOMMUFD version.
> 
> There's a gap between these two versions: the vfio_iommu_type1 version
> inputs a non-contiguous PFN list and outputs another PFN list for the
> pinned physical page list, while the IOMMUFD version only supports a
> contiguous address input by accepting the starting IO virtual address of a
> set of pages to pin and by outputting to a physical page list.
> 
> The nature of existing callers mostly aligns with the IOMMUFD version,
> except s390's vfio_ccw_cp code where some additional change is needed
> along with this series. Overall, updating to "iova" and "phys_page"
> does improve the caller side to some extent.
> 
> Also fix a misuse of physical address and virtual address in the s390's crypto
> code. And update the input naming at the adjacent vfio_dma_rw().
> 
> This is on github:
> https://github.com/nicolinc/iommufd/commits/vfio_pin_pages-v4
> 
> Terrence has tested this series on i915; Eric has tested on s390.
> 
> Thanks!
> 
> Changelog
> v4:
>  * Dropped double-shifting at two gvt_unpin_guest_page calls, fixing
>a bug that's discovered by Alex
>  * Added Reviewed-by from Anthony Krowiak
>  * Rebased on top of linux-vfio's next
> v3: https://lore.kernel.org/kvm/20220708224427.1245-1-
> nicol...@nvidia.com/
>  * Added a patch to replace roundup with DIV_ROUND_UP in i915 gvt
>  * Dropped the "driver->ops->unpin_pages" and NULL checks in PATCH-1
>  * Changed to use WARN_ON and separate into lines in PATCH-1
>  * Replaced "guest" words with "user" and fix typo in PATCH-5
>  * Updated commit log of PATCH-1, PATCH-6, and PATCH-10
>  * Added Reviewed/Acked-by from Christoph, Jason, Kirti, Kevin and Eric
>  * Added Tested-by from Terrence (i915) and Eric (s390)
> v2: https://lore.kernel.org/kvm/20220706062759.24946-1-
> nicol...@nvidia.com/
>  * Added a patch to make vfio_unpin_pages return void
>  * Added two patches to remove PFN list from two s390 callers
>  * Renamed "phys_page" parameter to "pages" for vfio_pin_pages
>  * Updated commit log of kmap_local_page() patch
>  * Added Harald's "Reviewed-by" to pa_ind patch
>  * Rebased on top of Alex's extern removal path
> v1: https://lore.kernel.org/kvm/20220616235212.15185-1-
> nicol...@nvidia.com/
> 
> Nicolin Chen (10):
>   vfio: Make vfio_unpin_pages() return void
>   drm/i915/gvt: Replace roundup with DIV_ROUND_UP
>   vfio/ap: Pass in physical address of ind to ap_aqic()
>   vfio/ccw: Only pass in contiguous pages
>   vfio: Pass in starting IOVA to vfio_pin/unpin_pages API
>   vfio/ap: Change saved_pfn to saved_iova
>   vfio/ccw: Change pa_pfn list to pa_iova list
>   vfio: Rename user_iova of vfio_dma_rw()
>   vfio/ccw: Add kmap_local_page() for memcpy
>   vfio: Replace phys_pfn with pages for vfio_pin_pages()
> 
>  .../driver-api/vfio-mediated-device.rst   |   6 +-
>  arch/s390/include/asm/ap.h|   6 +-
>  drivers/gpu/drm/i915/gvt/kvmgt.c  |  45 ++--
>  drivers/s390/cio/vfio_ccw_cp.c| 195 +++---
>  drivers/s390/crypto/ap_queue.c|   2 +-
>  drivers/s390/crypto/vfio_ap_ops.c |  54 +++--
>  drivers/s390/crypto/vfio_ap_private.h |   4 +-
>  drivers/vfio/vfio.c   |  54 ++---
>  drivers/vfio/vfio.h   |   8 +-
>  drivers/vfio/vfio_iommu_type1.c   |  45 ++--
>  include/linux/vfio.h  |   9 +-
>  11 files changed, 213 insertions(+), 215 deletions(-)

Verified the Intel KVMGT feature, no regression be introduced by v4 patch 
series, the previous Call Trace issue already gone.
Tested-by: Terrence Xu 
> --
> 2.17.1

Re: [Intel-gfx] [RFT][PATCH v2 0/9] Update vfio_pin/unpin_pages API

2022-07-08 Thread Xu, Terrence

> -Original Message-
> From: intel-gvt-dev  On Behalf Of
> On Thu, Jul 07, 2022 at 06:08:45AM +, Tian, Kevin wrote:
> 
> > > Request for testing: I only did build for s390 and i915 code, so
> > > it'd be nice to have people who have environment to run sanity 
> > > accordingly.
> > >
> >
> > +Terrence who is testing it for i915 now...
> 
> Hi Terrence, would it be possible for you to pull v3 to test on?
> https://github.com/nicolinc/iommufd/commits/dev/vfio_pin_pages-v3
> 
> They are basically same but there's a new DIV_ROUND_UP change, which
> shouldn't result in any functional difference, IMHO. If
> v3 passes, I can simply add your Tested-by when I respin it.

Hi Nicolin, I already completed KVMGT key feature testing based on your v3 
repo, VM booted up successfully and run smoothly, but there is a call trace 
during each time VM booting up, as the attachment.



call_trace.log
Description: call_trace.log

Re: [Intel-gfx] Various problems for the Xen for XenGT code and guide.

2020-09-01 Thread Xu, Terrence

Hi Mario,

Sorry to make you feel uncomfortable.

I think it is not setup guide problem, the main reason is the Xen code is very 
old (We are upgrading GVT-g code on Linux kernel side and we haven’t upgraded 
the Xen and Qemu source for XenGT for at least 2 years) but your GCC is new 
(You are using Ubuntu 20.4, the gcc version is 9+).

I have a way to workaround it, as below:

1.  apt-get install gcc-7
2.  ln -fs gcc-7 /usr/bin/gcc

Any more problem just let us know!

Thanks
Terrence

From: Mario Marietto 
Sent: Thursday, August 27, 2020 9:52 PM
To: Xu, Terrence ; igv...@lists.01.org; 
xen-de...@lists.xenproject.org; xen-de...@lists.xen.org; 
intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org; Li, Susie 
; Tian, Kevin ; Lv, Zhiyuan 
; Li, Weinan Z ; Downs, Mike 

Subject: Various problems for the Xen for XenGT code and guide.

Hello.

I would like to pass the integrated gpu from the host os (ubuntu 20.04) to the 
windows 10 guest os with xen. This is because xen works great for me,better 
than qemu-kvm for my specific needs and because I have only two graphic cards. 
The nvidia rtx 2080 ti that I have already passed to the guest,and the intel 
UHD 630,that can be duplicated from the host to the guest so that it can be 
used in both places without interruptions. So I'm trying to build this 
repository :

https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide#332-build-qemu--xen-for-xengt

I have to say that this guide is totally not very well written. And the code is 
full of unpatched bugs. It's a month that I'm working on that,trying to fix the 
bugs that are came out from the 2015 until today. This is not my job. This is 
my hobby. But,I need to activate the pass through for my integrated GPU so I 
don't to give up. I'm also very angry with those coders who do not do their job 
well and with those coders who do not respond to help messages. It is not 
enough to write good code to be a good programmer. It is also important to keep 
the documentation updated, to help those who cannot get the code to work. 
Anyway,I've documented every step that I did to make it work here :

https://github.com/intel/gvt-linux/issues/168

right now I'm trying to fix the bug n. 434544,that you can see below.

CC util/qemu-error.o
/etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c: In function ‘vreport’:
/etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:201:5: error: 
‘GTimeVal’ is deprecated: Use 'GDateTime' instead 
[-Werror=deprecated-declarations]
201 | GTimeVal tv;
| ^~~~
In file included from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/glib-compat.h:19,
from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/qemu/osdep.h:107,
from /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:13:
/usr/include/glib-2.0/glib/gtypes.h:547:8: note: declared here
547 | struct GTimeVal
| ^
/etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:205:9: error: 
‘g_get_current_time’ is deprecated: Use 'g_get_real_time' instead 
[-Werror=deprecated-declarations]
205 | g_get_current_time(&tv);
| ^~
In file included from /usr/include/glib-2.0/glib/giochannel.h:33,
from /usr/include/glib-2.0/glib.h:54,
from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/glib-compat.h:19,
from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/qemu/osdep.h:107,
from /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:13:
/usr/include/glib-2.0/glib/gmain.h:679:8: note: declared here
679 | void g_get_current_time (GTimeVal result);
| ^~
/etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:206:9: error: 
‘g_time_val_to_iso8601’ is deprecated: Use 'g_date_time_format' instead 
[-Werror=deprecated-declarations]
206 | timestr = g_time_val_to_iso8601(&tv);
| ^~~
In file included from /usr/include/glib-2.0/glib.h:88,
from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/glib-compat.h:19,
from /etc/xen/igvtg-xen/tools/qemu-xen-dir/include/qemu/osdep.h:107,
from /etc/xen/igvtg-xen/tools/qemu-xen-dir/util/qemu-error.c:13:
/usr/include/glib-2.0/glib/gtimer.h:73:10: note: declared here
73 | gchar g_time_val_to_iso8601 (GTimeVal *time) G_GNUC_MALLOC;
| ^
cc1: all warnings being treated as errors
any help is appreciated.  Someone must help me, thanking me for all the efforts 
I am making to make work a code full of errors. I would also know if I can 
activate the passthrough of the intel integrated gpu using the precompiled 
xen-hypervisor package that's on ubuntu. Right now I tried to compile it from 
scratch because I've thought that it was a necessary step,as described on the 
guide. But Im not sure on this point.

--
Mario.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q3 release of KVMGT (Intel GVT-g for KVM)

2018-11-19 Thread Xu, Terrence

Yes, if you find and problem on we mentioned platform, you can file a bug on 
fd. (https://bugs.freedesktop.org/)  with component "DRM/iGVT-g".

>-Original Message-
>From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
>Sent: Friday, November 16, 2018 10:34 PM
>To: 'igv...@lists.01.org' ; 'intel-
>g...@lists.freedesktop.org' ;
>'k...@vger.kernel.org' ; 'linux-
>ker...@vger.kernel.org' ; Xu, Terrence
>
>Cc: Li, Susie ; Wang, Zhenyu Z
>; Cowperthwaite, David J
>; Reddy, Raghuveer
>; Dong, Eddie ; Yuan,
>Hang ; Lv, Zhiyuan ; Jin,
>Gordon ; Downs, Mike ;
>Wang, Hongbo 
>Subject: Re: [Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q3 release of KVMGT
>(Intel GVT-g for KVM)
>
>Quoting Xu, Terrence (2018-10-19 10:04:47)
>> Platform Support:
>>
>> -Server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with Intel
>> Graphics processor
>>
>> -Client platforms: Intel(r) Core(tm) 5th generation (code name:
>Broadwell),
>> 6th generation (code name: Skylake), 7th generation (code name:
>> Kabylake) and 7th SoC generation (code name: Broxton), the Broxton is
>> new supported platform
>
>Does this mean that all SKUs from those platforms are supported so that
>when users report bugs, they will be worked on?
>
>Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q3 release of XenGT (Intel GVT-g for Xen)

2018-10-19 Thread Xu, Terrence

Hi all,



We are pleased to announce an 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 processor 
graphics. 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. GVT-g for Xen hypervisor is XenGT.





Repositories

-Kernel: https://github.com/01org/gvt-linux (tag: 2018-q3-gvt-stable-4.17)

-Qemu: https://github.com/01org/igvtg-qemu (tag: 2018-q3-stable-2.12.0)

-Xen :  https://github.com/01org/igvtg-xen (tag: 2018-q1-xengt-stable-4.10)



Platform Support

-Server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with Intel 
Graphics processor

-Client platforms: Intel(r) Core(tm) 5th generation (code name: Broadwell), 
6th generation (code name: Skylake) and 7th generation (code name: Kabylake)



Guest Operation System Validated

-Windows7 32-bit, Window7 64-bit, Windows8.1 64-bit, Windows10 64-bit

-Ubuntu 18.04 64-bit



Major Changes since Q1'2018 Release

-This update is based on kernel version 4.17 and Qemu version 2.12.

-More bug fixing and code refinement, please refer to git log.



Limitation or known issues:

-Windows gfx driver 25.20.100.6326 is preferred for Windows 10 VM.

-Due to graphics hardware resource limitation, the maximum number of 
Windows VM is 7.

-The pre-defined type vgt_low_gm_sz=128/256/512 of option into HVM file 
must be created for VM to install Windows 7 32-bit. vGPU type 8 is not 
allocated to have enough graphics resource to support Windows 7 32-bit.

-If the default 1024x768 vm screen resolution couldn't satisfy your need, 
please add vgt_log_gm_sz=128/256/512 option into HVM file.

-There's corner case that Guest Windows 7 32bit VM may be killed 
automatically by Xen when Guest VM runs into TDR. This issues happens only on 
Broadwell platform. The workaround is to disable part of viridian feature in 
Guest VM hvm file by adding viridian=["all", "!apic_assist"].





Useful links:

-Setup guide:

https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide



-New upstream architecture design introduction:

https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction



-Please subscribe to join the mailing list if you want to learn more about 
GVT-g project:

https://lists.01.org/mailman/listinfo/igvt-g



-Please subscribe to join the mailing list if you want to contribute/review 
latest GVT-g upstream patches:

https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev



-Official GVT-g portal:

https://01.org/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





Important 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

Terrence

Tel: +86-21-6116 5390

MP: +86-1356 4367 024

Mail: terrence...@intel.com



___

GVT-g mailing list

igv...@lists.01.org
https://lists.01.org/mailman/listinfo/igvt-g
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q3 release of KVMGT (Intel GVT-g for KVM)

2018-10-19 Thread Xu, Terrence

Hi all,



We are pleased to announce an update of Intel GVT-g for KVM.



Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
mediated pass-through, starting from 5th generation Intel Core(TM) processors 
with Intel processor graphics.  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.





Repositories:

-Kernel: https://github.com/01org/gvt-linux  (tag: 2018-q3-gvt-stable-4.17)

-Qemu: https://github.com/01org/igvtg-qemu  (tag: 2018-q3-stable-2.12.0)



Platform Support:

-Server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with Intel 
Graphics processor

-Client platforms: Intel(r) Core(tm) 5th generation (code name: Broadwell), 
6th generation (code name: Skylake), 7th generation (code name: Kabylake) and 
7th SoC generation (code name: Broxton), the Broxton is new supported platform



Guest Operation System Validated:

-Windows7 32-bit, Window7 64-bit, Windows8.1 64-bit, Windows10 64-bit

-Ubuntu 18.04 64-bit



Major Changes since Q1'2018 Release:

-This update is based on kernel version 4.17 and Qemu version 2.12.

-Add the Broxton platform preliminary support for KVMGT.

-Improve stability of dma-buf feature with some GPU reset issues be fixed.

-More bug fixing and code refinement, please refer to git log.



Limitation or known issues:

-Due to graphics hardware resource limitation, the maximum number of 
Windows VM is 7.

-The pre-defined type 1, 2 or 4 of vGPU must be created for VM to install 
Windows 7 32-bit. vGPU type 8 is not allocated to have enough graphics resource 
to support Windows 7 32-bit.

-Some 3rd party applications/tools like GPU_Z, Passmark 9.0 running in 
Windows VM may meet BSOD error. The workaround is to add "kvm.ignore_msrs=1" in 
host kernel's command line to avoid this.

-There are still instability issues about Guest VM stability while the 
IOMMU feature is enabled on a few Broadwell and Kabylake machines. The 
workaround is to turn off IOMMU on Intel graphics device by adding 
"intel_iommu=igfx_off"  in Host kernel's command line.
-For Broxton, only Linux guest is currently supported, and the Linux guest 
kernel must be the same as the host kernel.





Useful links:

-Setup guide:

https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide



-New upstream architecture design introduction:

https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction



-Please subscribe to join the mailing list if you want to learn more about 
GVT-g project:

https://lists.01.org/mailman/listinfo/igvt-g



-Please subscribe to join the mailing list if you want to contribute/review 
latest GVT-g upstream patches:

https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev



-Official GVT-g portal:

https://01.org/igvt-g



-More information about background, architecture and others about Intel 
GVT-g, can be found at:

http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf

https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian





Important Note:

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

Terrence

Tel: +86-21-6116 5390

MP: +86-1356 4367 024

Mail: terrence...@intel.com



___

GVT-g mailing list

igv...@lists.01.org

https://lists.01.org/mailman/listinfo/igvt-g

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q1 release of XenGT (Intel GVT-g for Xen)

2018-04-20 Thread Xu, Terrence

Hi all,

We are pleased to announce an 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 processor
graphics. 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. GVT-g for Xen hypervisor is XenGT.

Repositories

-Xen : https://github.com/01org/igvtg-xen (tag: 2018-q1-xengt-stable-4.10)

-Kernel: https://github.com/01org/gvt-linux (tag: 2018-q1-gvt-stable-4.14)

-Qemu: https://github.com/01org/igvtg-qemu (tag: 2018-q1-stable-2.10.0)

Platform Support

-Server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with Intel
Graphics processor

-Client platforms: Intel(r) Core(tm) 5th generation (code name: Broadwell),
6th generation (code name: Skylake) and 7th generation (code name: Kabylake)

Guest Operation System Validated

-Windows7 32-bit, Window7 64-bit, Windows8.1 64-bit, Windows10 64-bit

-Ubuntu 16.04 64-bit

Major Changes from Q3'2017 Release

-This update is based on kernel version 4.14 and Qemu version 2.10 and Xen
4.10.

-Improve stability of Live Migration feature with internal stress test
passed.

-More bug fixing, code refinement and debugging interface enhancement,
please refer to git log.

Limitation or known issues:

-Due to graphics hardware resource limitation, the maximum number of
Windows VM is 7.

-The pre-defined type vgt_low_gm_sz=128/256/512 of option into HVM file
must be created for VM to install Windows 7 32-bit. vGPU type 8 is not
allocated to have enough graphics resource to support Windows 7 32-bit.

-If the default 1024x768 vm screen resolution couldn't satisfy your need,
please add vgt_log_gm_sz=128/256/512 option into HVM file.

-Due to one known regression issue in latest Intel Windows Graphics driver,
Intel Windows Graphics driver version 15.45 is preferred to install in Windows
VM and please don't enable Windows auto-update mechanism to update the driver
to later version. Some 3rd party applications like 3DMark rely on DirectX12
features. DirectX12 is not supported in Intel Windows Graphics driver 15.45 or
earlier versions. So the applications will not run well in Windows VM with
these drivers.

-There's corner case that Guest Windows 7 32bit VM may be killed
automatically by Xen when Guest VM runs into TDR. This issues happens only on
Broadwell platform. The workaround is to disable part of viridian feature in
Guest VM hvm file by adding viridian=["all", "!apic_assist"].

Useful links:

-Setup guide:

https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide

-New upstream architecture design introduction:

https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction

-Please subscribe to join the mailing list if you want to learn more about
GVT-g project:

https://lists.01.org/mailman/listinfo/igvt-g

-Please subscribe to join the mailing list if you want to contribute/review
latest GVT-g upstream patches:

https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-Official GVT-g portal:

https://01.org/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

Important 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

Terrence

Tel: +86-21-6116 5390

MP: +86-1356 4367 024

Mail: terrence...@intel.com

___

GVT-g mailing list

igv...@lists.01.org

https://lists.01.org/mailman/listinfo/igvt-g

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q1 release of KVMGT (Intel GVT-g for KVM)

2018-04-20 Thread Xu, Terrence

Hi all,



We are pleased to announce an update of Intel GVT-g for KVM.



Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
mediated pass-through, starting from 5th generation Intel Core(TM) processors 
with Intel processor graphics.  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.





Repositories:

-Kernel: https://github.com/01org/gvt-linux  (tag: 2018-q1-gvt-stable-4.14)

-Qemu: https://github.com/01org/igvtg-qemu  (tag: 2018-q1-stable-2.10.0)



Platform Support:

-Server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with Intel 
Graphics processor

-Client platforms: Intel(r) Core(tm) 5th generation (code name: Broadwell), 
6th generation (code name: Skylake) and 7th generation (code name: Kabylake)



Guest Operation System Validated:

-Windows7 32-bit, Window7 64-bit, Windows8.1 64-bit, Windows10 64-bit

-Ubuntu 16.04 64-bit



Major Changes from Q3'2017 Release:

-This update is based on kernel version 4.14 and Qemu version 2.10.

-Improve stability of Live Migration feature with internal stress test 
passed.

-Implement dmabuf-based Guest VM framebuffer sharing. With adding GTK and 
Spice dmabuf support in Qemu (to be in Qemu 2.12), local and remote display use 
cases are preliminarily enabled.

-Improve GVT health on IOMMU enabled platform by fixing high DMA setup 
overhead issue.

-More bug fixing, code refinement and debugging interface enhancement, 
please refer to git log.



Limitation or known issues:

-Due to graphics hardware resource limitation, the maximum number of 
Windows VM is 7.

-The pre-defined type 1, 2 or 4 of vGPU must be created for VM to install 
Windows 7 32-bit. vGPU type 8 is not allocated to have enough graphics resource 
to support Windows 7 32-bit.

-Some 3rd party applications/tools like GPU_Z, Passmark 9.0 running in 
Windows VM may meet BSOD error. This happens when these applications try to 
access some un-emulated Model Specific Registers in KVM. The workaround is to 
add "kvm.ignore_msrs=1" in host kernel's command line to avoid this.

-Due to one known regression issue in latest Intel Windows Graphics driver, 
Intel Windows Graphics driver version 15.45 is preferred to install in Windows 
VM and please don't enable Windows auto-update mechanism to update the driver 
to later version. Some 3rd party applications like 3DMark rely on DirectX12 
features. DirectX12 is not supported in Intel Windows Graphics driver 15.45 or 
earlier versions. So the applications will not run well in Windows VM with 
these drivers.

-There's case about Guest VM stability while the IOMMU feature is enabled. 
The issues happens on a few Broadwell and Kabylake platforms. There are still 
instability issues seen on a few Broadwell and Kabylake machines when IOMMU is 
enabled in Host. The workaround is to turn off IOMMU on Intel graphics device 
by adding "intel_iommu=igfx_off"  in Host kernel's command line.





Useful links:

-Setup guide:

https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide



-New upstream architecture design introduction:

https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction



-Please subscribe to join the mailing list if you want to learn more about 
GVT-g project:

https://lists.01.org/mailman/listinfo/igvt-g



-Please subscribe to join the mailing list if you want to contribute/review 
latest GVT-g upstream patches:

https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev



-Official GVT-g portal:

https://01.org/igvt-g



-More information about background, architecture and others about Intel 
GVT-g, can be found at:

http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf

https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian





Important Note:

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

Terrence

Tel: +86-21-6116 5390

MP: +86-1356 4367 024

Mail: terrence...@intel.com



___

GVT-g mailing list

igv...@lists.01.org

https://lists.01.org/mailman/listinfo/igvt-g


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GVT-g] [ANNOUNCE] 2017-Q3 release of XenGT (Intel GVT-g for Xen)

2017-10-10 Thread Xu, Terrence

Hi all,

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

Repositories
- Xen : https://github.com/01org/igvtg-xen (tag: 2017-q3-xengt-stable-4.9)
- Kernel: https://github.com/01org/gvt-linux/ (tag: 2017-q3-gvt-stable-4.12)
- Qemu: https://github.com/01org/igvtg-qemu (tag: 2017-q3-stable-2.9.0)

This update consists of:
- Kernel version upgraded to 4.12 from 4.11.
- Live migration feature preliminary supported.
- QoS feature preliminary supported.
- IOMMU feature supported.
- OVMF feature supported.
- VGPU reset feature optimization, with related issues be fixed.
- Supported server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with
Intel Graphics processor, E3_v6 is new supported platform.
- Supported client platforms: Intel(r) Core(tm) 5th generation (code name:
Broadwell), 6th generation (code name: Skylake) and 7th generation (code name:
Kabylake), 7th generation is new supported platform.
- Validated Guest OS: Windows7 32bit, Window7 64bit, Windows8.1 64bit,
Windows10 64bit and Linux.
- GVT-g only supports remote display not local display by this release.
- Remote protocol: only guest-side remoting protocol is supported, host-side
remoting connection like SPICE is working in progress. For example, user can
use X11VNC for Guest Linux VM or TightVNC for Guest Windows VM.

Limitation or known issues:
- GVT-g can support maximum 7 Guest VMs due to host graphics resource
limitation. When user runs 7 VMs simultaneously, host OS can only run in text
mode.
- In order to support Guest Windows7 32bit VM, user is recommended to
configure vgt_low_gm_sz=128 / 256 / 512 in HVM file because Guest Windows7
32bit VM needs more graphics resource than other Guest VM.
- In order to support Guest VM high resolution and screen resolution
adjustable in Guest Windows8.1 64bit VM and Guest Windows10 64bit VM, user is
recommended to configure vgt_low_gm_sz=64 / 128 / 256 / 512 in HVM file to get
larger VM aperture size.
- Some 3rd party applications/tools like 3DMark which including special
DirectX12 feature test ,it will trigger Guest VM GPU reset.
- In corner case, Guest Windows 7 32bit VM may be killed automatically by
Xen when Guest VM runs into TDR. This issues happens only on Broadwell
platform. The workaround is to disable part of viridian feature in Guest VM hvm
file by adding viridian=["all", "!apic_assist"].
- In corner case, Linux Guest VM may GPU hang while running special
Intel-GPU-Tools test case on it.
- For live migration feature, we cannot migrate Guest Windows VM when Guest
VM memory is 2048M or 4096M, user is recommended to configure Guest VM memory
to 1024MB.

Setup guide:
https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide

This is the first GVT-g community release based on new Upstream architecture
design, refer to the following document for new architecture introduction:
https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction

Please subscribe to join the mailing list if you want to learn more about GVT-g
project:
https://lists.01.org/mailman/listinfo/igvt-g
Please subscribe to join the mailing list if you want to contribute/review
latest GVT-g upstream patches:
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

Official GVT-g portal:
https://01.org/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.

Thanks
Terrence
Tel: +86-21-6116 5390
MP: +86-1356 4367 024
Mail: terrence...@intel.com

___
GVT-g mailing list
igv...@lists.01.org
https://lists.01.org/mailman/listinfo/igvt-g

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___

[Intel-gfx] [GVT-g] [ANNOUNCE] 2017-Q3 release of KVMGT (Intel GVT-g for KVM)

2017-10-10 Thread Xu, Terrence

Hi all,

We are pleased to announce an update of Intel GVT-g for KVM.

Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
mediated pass-through, starting from 5th generation Intel Core(TM) processors 
with Intel processor graphics.  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.
    

Repositories:
-    Kernel: https://github.com/01org/gvt-linux/  (tag: 2017-q3-gvt-stable-4.12)
-    Qemu: https://github.com/01org/igvtg-qemu  (tag: 2017-q3-stable-2.9.0)


This update consists of:
-    Kernel version upgraded to 4.12 from 4.11.
-    Live migration feature preliminary supported.
-    QoS feature preliminary supported.
-    IOMMU feature supported.
-    OVMF feature supported.
-    VGPU reset feature optimization, with related issues be fixed.
-    Supported server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with 
Intel Graphics processor, the E3_v6 is new supported platform.
-    Supported client platforms: Intel(r) Core(tm) 5th generation (code name: 
Broadwell), 6th generation (code name: Skylake) and 7th generation (code name: 
Kabylake), the 7th generation is new supported platform.
-    Validated Guest OS: Windows7 32bit, Window7 64bit, Windows8.1 64bit, 
Windows10 64bit and Linux.
-    GVT-g only supports remote display not local display by this release. 
-    Remote protocol: only guest-side remoting protocol is supported, host-side 
remoting connection like SPICE is working in progress. For example, user can 
use X11VNC for Guest Linux VM or TightVNC for Guest Windows VM.


Limitation or known issues:
-    GVT-g can support maximum 7 Guest VMs due to host graphics resource 
limitation. When user runs 7 VMs simultaneously, host OS can only run in text 
mode.
-    In order to support Guest Windows7 32bit VM, user can only uses vGPU 
type1, type2, type4 not type8 because Guest Windows7 32bit VM needs more 
graphics resource than other Guest VM.
-    Some 3rd party applications/tools like GPU_Z, Passmark 9.0 may read/write 
GPU MSR directly, it will trigger Guest VM BSOD since those MSRs are unhandled 
registers in KVMGT. The workaround is to set MSR read /write ignore flag to 1 
in host grub file by adding "kvm.ignore_msrs=1".
-    Some 3rd party applications/tools like 3DMark which including special 
DirectX12 feature test ,it will trigger Guest VM GPU reset.
-    In corner case, Linux Guest VM may GPU hang while running special 
Intel-GPU-Tools test case on it.
-    In corner case, for live migration feature, the fake GPU reset happening 
while migrating Linux Guest VM which Guest VM running 3D workload.  
-    Guest Windows VM often GPU hang while the IOMMU feature enabled. This 
issues happens only on a few Broadwell platforms due to the hardware problem. 
The workaround is to turn off the integrated graphics engine on IOMMU in hot 
grub file by adding "intel_iommu=igfx_off".


Setup guide:
https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide


This is the first GVT-g community release based on new Upstream architecture 
design, refer to the following document for new architecture introduction:
https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction 


Please subscribe to join the mailing list if you want to learn more about GVT-g 
project: 
https://lists.01.org/mailman/listinfo/igvt-g
Please subscribe to join the mailing list if you want to contribute/review 
latest GVT-g upstream patches:
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev


Official GVT-g portal:
https://01.org/igvt-g


More information about background, architecture and others about Intel GVT-g, 
can be found at:
http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian


Note:
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
Terrence
Tel: +86-21-6116 5390
MP: +86-1356 4367 024
Mail: terrence...@intel.com

___
GVT-g mailing list
igv...@lists.01.org
https://lists.01.org/mailman/listinfo/igvt-g

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GVT-g] [ANNOUNCE] 2017-Q2 release of KVMGT (Intel GVT-g for KVM)

2017-06-20 Thread Xu, Terrence

Hi all,

We are pleased to announce an update of Intel GVT-g for KVM.

Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with 
mediated pass-through, starting from 5th generation Intel Core(TM) processors 
with Intel processor graphics.  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.


Repositories:
-Kernel: https://github.com/01org/gvt-linux/  (tag: 2017-q2-gvt-stable-4.11)
-Qemu: https://github.com/01org/igvtg-qemu  (tag: 2017-q2-stable-2.9.0)


This update consists of:
-GVT-g upgraded to new architecture which has been upstreamed from kernel 
4.10.
-QEMU version upgraded to 2.9 from 2.3 (There is no any specific code 
changes in QEMU for KVMGT,  so people could directly use upstream QEMU as an 
alternative).
-Supported server platforms: Intel(r) Xeon(r) E3_v4 and E3_v5 with Intel 
Graphics processor. 
-Supported client platforms: Intel(r) Core(tm) 5th generation (code name: 
Broadwell) and 6th generation (code name: Skylake). 
-Validated Guest OS: Windows7 32bit, Window7 64bit, Windows8.1 64bit, 
Windows10 64bit and Linux.
-GVT-g only supports remote display not local display by this release. 
-Remote protocol: only guest-side remoting protocol is supported, host-side 
remoting connection like SPICE is working in progress. For example, user can 
use X11VNC for Guest Linux VM or TightVNC for Guest Windows VM.


Limitation or known issues:
-GVT-g can support maximum 7 Guest VMs due to host graphics resource 
limitation. When user runs 7 VMs simultaneously, host OS can only run in text 
mode.
-In order to support Guest Windows7 32bit VM, user can only uses vGPU 
type1, type2, type4 not type8 because Guest Windows7 32bit VM needs more 
graphics resource than other Guest VM.
-Some 3rd party applications/tools like GPU_Z, Passmark 9.0 may read/write 
GPU MSR directly, it will trigger VM BSOD since those MSRs are unhandled 
registers in KVMGT. The workaround is to set MSR read /write ignore flag to 1 
in host grub file by adding "kvm.ignore_msrs=1".
-In corner case, Guest Linux VM virtual display screen may freeze and not 
be able to recover when Guest VM runs into a TDR, but the Guest VM is still 
running and alive which can be accessed through SSH.



Setup guide:
https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide


This is the first GVT-g community release based on new Upstream architecture 
design, refer to the following document for new architecture introduction:
https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction 


Please subscribe to join the mailing list if you want to learn more about GVT-g 
project: 
https://lists.01.org/mailman/listinfo/igvt-g
Please subscribe to join the mailing list if you want to contribute/review 
latest GVT-g upstream patches:
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev


Official GVT-g portal:
https://01.org/igvt-g


More information about background, architecture and others about Intel GVT-g, 
can be found at:
http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian


Note:
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
Terrence
Tel: +86-21-6116 5390
MP: +86-1356 4367 024
Mail: terrence...@intel.com

___
iGVT-g mailing list
igv...@lists.01.org
https://lists.01.org/mailman/listinfo/igvt-g

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [GVT-g] [ANNOUNCE] 2017-Q2 release of XenGT (Intel GVT-g for Xen)

2017-06-20 Thread Xu, Terrence

Hi all,

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

Repositories
-Xen : https://github.com/01org/igvtg-xen (tag: 2017-q2-xengt-stable-4.9)
-Kernel: https://github.com/01org/gvt-linux/ (tag: 2017-q2-gvt-stable-4.11)
-Qemu: https://github.com/01org/igvtg-qemu (tag: 2017-q2-stable-2.9.0)

This update consists of:
-GVT-g upgraded to new architecture which has been upstreamed from kernel
4.10.
-QEMU version upgraded to 2.9 from 2.3.
-Xen version upgraded to 4.9 from 4.6.
-Supported server platforms: Intel(r) Xeon(r) E3_v4 and E3_v5 with Intel
Graphics processor.
-Supported client platforms: Intel(r) Core(tm) 5th generation (code name:
Broadwell) and 6th generation (code name: Skylake).
-Validated Guest OS: Windows7 32bit, Window7 64bit, Windows8.1 64bit,
Windows10 64bit and Linux.
-GVT-g only supports remote display not local display by this release.
-Remote protocol: only guest-side remoting protocol is supported, host-side
remoting connection like SPICE is working in progress. For example, user can
use X11VNC for Guest Linux VM or TightVNC for Guest Windows VM.

Limitation or known issues:
-GVT-g can support maximum 7 Guest VMs due to host graphics resource
limitation. When user runs 7 VMs simultaneously, host OS can only run in text
mode.
-In order to support Guest Windows7 32bit VM, user is recommended to add
vgt_low_gm_sz=128 in HVM file because Guest Windows7 32bit VM needs more
graphics resource than other Guest VM.
-In order to support Guest VM high resolution and screen resolution
adjustable in Guest Windows8.1 64bit VM and Guest Windows10 64bit VM, user is
recommended to configure vgt_low_gm_sz=64 / 128 / 256 / 512 in HVM file to get
larger VM aperture size.
-In corner case, Guest Windows 8.1 64bit VM may be killed automatically by
Xen when Guest VM runs into TDR. This issues happens only on Broadwell platform.
-In corner case, Guest Windows VMs may be killed automatically by Xen when
user shutdowns the last launched Guest Windows VM. This issues happens only on
Broadwell platform.
-In corner case, Guest Linux VM virtual display screen may freeze and not
be able to recover when Guest VM runs into a TDR, but the Guest VM is still
running and alive which can be accessed through SSH.

Setup guide:
https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide

Official GVT-g portal:
https://01.org/igvt-g

Thanks
Terrence
Tel: +86-21-6116 5390
MP: +86-1356 4367 024
Mail: terrence...@intel.com

___
iGVT-g mailing list
igv...@lists.01.org
https://lists.01.org/mailman/listinfo/igvt-g

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly

2017-03-17 Thread Xu, Terrence



>-Original Message-
>From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
>Sent: Friday, March 17, 2017 5:30 PM
>To: Zhenyu Wang 
>Cc: Chris Wilson ; Tvrtko Ursulin
>; Intel-gfx@lists.freedesktop.org; Ursulin, Tvrtko
>; Li, Weinan Z ; Xu,
>Terrence 
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/vgpu: Neuter forcewakes for VGPU
>more thouroughly
>
>
>Hi,
>
>On 13/03/2017 09:37, Zhenyu Wang wrote:
>> On 2017.03.13 09:26:26 +, Tvrtko Ursulin wrote:
>>>
>>> On 10/03/2017 10:09, Chris Wilson wrote:
>>>> On Fri, Mar 10, 2017 at 09:57:47AM +, Tvrtko Ursulin wrote:
>>>>> From: Tvrtko Ursulin 
>>>>>
>>>>> If we avoid initializing forcewake domains when running as a guest,
>>>>> and also use gen2 mmio accessors in that case, we can avoid the
>>>>> timer traffic and any looping through the forcewake code which is
>>>>> currently just so it can end up in the no-op forcewake
>>>>> implementation.
>>>>>
>>>>> Signed-off-by: Tvrtko Ursulin 
>>>>> Cc: Weinan Li 
>>>>> Cc: Chris Wilson 
>>>>> ---
>>>>>  drivers/gpu/drm/i915/intel_uncore.c | 76
>>>>> +
>>>>>  1 file changed, 27 insertions(+), 49 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
>>>>> b/drivers/gpu/drm/i915/intel_uncore.c
>>>>> index 71b9b387ad04..09f5f02d7901 100644
>>>>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>>>>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>>>>> @@ -138,13 +138,6 @@ fw_domains_put(struct drm_i915_private
>>>>> *dev_priv, enum forcewake_domains fw_doma  }
>>>>>
>>>>>  static void
>>>>> -vgpu_fw_domains_nop(struct drm_i915_private *dev_priv,
>>>>> - enum forcewake_domains fw_domains)
>>>>> -{
>>>>> - /* Guest driver doesn't need to takes care forcewake. */
>>>>> -}
>>>>> -
>>>>> -static void
>>>>>  fw_domains_posting_read(struct drm_i915_private *dev_priv)  {
>>>>>   struct intel_uncore_forcewake_domain *d; @@ -1187,7 +1180,7
>@@
>>>>> static void fw_domain_init(struct drm_i915_private *dev_priv,
>>>>>
>>>>>  static void intel_uncore_fw_domains_init(struct drm_i915_private
>>>>> *dev_priv)  {
>>>>> - if (INTEL_INFO(dev_priv)->gen <= 5)
>>>>> + if (INTEL_GEN(dev_priv) <= 5 || intel_vgpu_active(dev_priv))
>>>>
>>>> Make these separate ifs, they aren't semantically related so be verbose.
>>>>
>>>>>   return;
>>>>>
>>>>>   if (IS_GEN9(dev_priv)) {
>>>>> @@ -1273,11 +1266,6 @@ static void
>intel_uncore_fw_domains_init(struct drm_i915_private *dev_priv)
>>>>>  FORCEWAKE, FORCEWAKE_ACK);
>>>>>   }
>>>>>
>>>>> - if (intel_vgpu_active(dev_priv)) {
>>>>> - dev_priv->uncore.funcs.force_wake_get =
>vgpu_fw_domains_nop;
>>>>> - dev_priv->uncore.funcs.force_wake_put =
>vgpu_fw_domains_nop;
>>>>> - }
>>>>> -
>>>>>   /* All future platforms are expected to require complex power gating
>*/
>>>>>   WARN_ON(dev_priv->uncore.fw_domains == 0);  } @@ -1327,22
>>>>> +1315,22 @@ void intel_uncore_init(struct drm_i915_private
>*dev_priv)
>>>>>   dev_priv->uncore.pmic_bus_access_nb.notifier_call =
>>>>>   i915_pmic_bus_access_notifier;
>>>>>
>>>>> - switch (INTEL_INFO(dev_priv)->gen) {
>>>>> - default:
>>>>> - case 9:
>>>>> - ASSIGN_FW_DOMAINS_TABLE(__gen9_fw_ranges);
>>>>> - ASSIGN_WRITE_MMIO_VFUNCS(fwtable);
>>>>> - ASSIGN_READ_MMIO_VFUNCS(fwtable);
>>>>> - if (HAS_DECOUPLED_MMIO(dev_priv)) {
>>>>> - dev_priv->uncore.funcs.mmio_readl =
>>>>> - gen9_decoupled_read32;
>>>>> - dev_priv->uncore.funcs.mmio_readq =
>>>>> - gen9_decoupled_read64;
>>>>> - dev_priv->uncore.funcs.mmio_writel =
>>>>> - gen9_decoupled_write32;
>>>>> + if (IS_GEN(dev_priv, 2, 4) || intel_vgpu_active(dev_priv)) {
>>>>
>>>> Ok, this doesn't look too bad.
>>>>
>>>> Do the gvt-g hosts in CI now provide coverage for us of vgpu paths?
>>>
>>> No idea.
>>>
>>> Adding Zhenyu. So this patch avoids burning CPU cycles in guests and
>>> scheduling timers when all of that ends up in the dummy/no-op
>>> forcewake implementation.
>>>
>>> If interesting to you, would it be easy for you to test it or how
>>> should we proceed?
>>>
>>
>> Patch looks fine to me. I can apply it for our QA testing if required.
>
>Were you perhaps able to smoke test this one?

Hi Ursulin, we have verified your patch in guest, no regression be found.

Tested-by: Terrence Xu  

>Regards,
>
>Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v3] Add the new tool for create GVT-g Linux guest based on KVMGT

2017-03-09 Thread Xu, Terrence

Thanks Petri, agree with all your comments!

Thanks
Terrence

>-Original Message-
>From: Latvala, Petri
>Sent: Thursday, March 9, 2017 6:58 PM
>To: Xu, Terrence 
>Cc: intel-gfx@lists.freedesktop.org; Jin, Gordon ; 
>Sarvela,
>Tomi P ; Lv, Zhiyuan ; Wang,
>Zhenyu Z ; Wang, Hongbo
>; Xu, BenyuX 
>Subject: Re: [PATCH i-g-t v3] Add the new tool for create GVT-g Linux guest 
>based
>on KVMGT
>
>On Fri, Mar 10, 2017 at 03:34:49AM +0800, Terrence Xu wrote:
>> GVT-g (Intel(r) Graphics Virtualization Technology) is a full GPU
>> virtualization solution with mediated pass-through support.
>>
>> This tool is for create basic Linux guest based on KVMGT with VFIO
>> framework, it including create vgpu, create guest, check IP address,
>> destroy guest, remove vgpu,check dmesg log, etc functions.
>>
>> v2: Treat this case as a free-standing tool, with detect & skip when
>> it's not running on GVT-g capable platform or running without the
>> required tools.
>>
>> v3: Make some optimizations: like "update the generate mac address
>> scripts", "provide more useful information for end user", etc.
>>
>> Signed-off-by: Terrence Xu 
>> Signed-off-by: Benyu Xu 
>> ---
>>  tools/.gitignore|   1 +
>>  tools/Makefile.sources  |   1 +
>>  tools/intel_gvtg_test.c | 359
>> 
>>  3 files changed, 361 insertions(+)
>>  create mode 100644 tools/intel_gvtg_test.c
>>
>> diff --git a/tools/.gitignore b/tools/.gitignore index
>> 13825a3..f777f2b 100644
>> --- a/tools/.gitignore
>> +++ b/tools/.gitignore
>> @@ -30,5 +30,6 @@ intel_reg_checker
>>  intel_residency
>>  intel_stepping
>>  intel_watermark
>> +intel_gvtg_test
>>  skl_compute_wrpll
>>  skl_ddb_allocation
>
>
>Sort alphabetically.
>
>
>> diff --git a/tools/Makefile.sources b/tools/Makefile.sources index
>> e2451ea..5f1e747 100644
>> --- a/tools/Makefile.sources
>> +++ b/tools/Makefile.sources
>> @@ -30,6 +30,7 @@ tools_prog_lists = \
>>  intel_stepping  \
>>  intel_watermark \
>>  intel_gem_info  \
>> +intel_gvtg_test \
>>  $(NULL)
>>
>>  dist_bin_SCRIPTS = intel_gpu_abrt
>> diff --git a/tools/intel_gvtg_test.c b/tools/intel_gvtg_test.c new
>> file mode 100644 index 000..ec6dd99
>> --- /dev/null
>> +++ b/tools/intel_gvtg_test.c
>> @@ -0,0 +1,359 @@
>> +/*
>> + * Copyright 2016 Intel Corporation
>> + *   Terrence Xu 
>> + *
>
>
>This should be
>
>
> * Copyright (c) 2016-2017 Intel Corporation
>
>
>> + * Permission is hereby granted, free of charge, to any person
>> + obtaining a
>> + * copy of this software and associated documentation files (the
>> + "Software"),
>> + * to deal in the Software without restriction, including without
>> + limitation
>> + * the rights to use, copy, modify, merge, publish, distribute,
>> + sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom
>> + the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + included in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + EXPRESS OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> + MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>EVENT
>> + SHALL THE
>> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
>OR
>> + OTHER
>> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> + ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + OTHER DEALINGS
>> + * IN THE SOFTWARE.
>> + */
>> +
>> +/*
>> + * This program is intended for testing of validate GVT-g virtual
>> +machine
>> + * creation of allow for testing of KVMGT / XenGT (the tool should be
>> +root
>> + * privilege only).
>> + *
>> + * TODO:
>> + * Enable more GVT-g related test cases.
>> + */
>> +#ifdef HAVE_CONFIG_H
>> +#include "config.h"
>> +#endif
>> +
>> +#include "igt.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
&

Re: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest based on KVMGT

2017-02-27 Thread Xu, Terrence


>On 02/27/2017 10:13 AM, Xu, Terrence wrote:
>> [Xu, Terrence] Yes the root is needed for all our "echo" related commands,
>can I suppose the case is running under root privilege? Or need to return
>"skip" when it is not under root privilege?
>>
>
>Right, seems I was a bit confused there and there are other cases where root
>rights are required.
>
>Assuming root privileges is fine, especially if you're nice and warn the user 
>if
>proper rights are not active. Can the tool be used as a normal user at all?
[Xu, Terrence] It cannot be used as a normal user, since it need to call the 
sysfs, so I will choose to warn the user if proper rights are not active. :)

>
>--
>Petri Latvala
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest based on KVMGT

2017-02-27 Thread Xu, Terrence

ar *retmsg, int msg_len) {
>> +FILE *fp;
>> +int res = -1;
>> +if (cmd == NULL || retmsg == NULL || msg_len < 0) {
>> +igt_info("Error: %s system paramer invalid!\n", __func__);
>
>paramer -> parameter
>
>
>> +return 1;
>> +}
>> +fp = popen(cmd, "r");
>> +if (fp == NULL) {
>> +perror("popen");
>> +igt_info("Error: %s popen error: %s\n", __func__, strerror(errno));
>> +return 2;
>> +} else {
>> +memset(retmsg, 0, msg_len);
>> +while (fgets(retmsg, msg_len, fp)) {
>> +;
>> +};
>
>
>Remove that semicolon after while's body's closing brace.
>
>
>> +res = pclose(fp);
>> +if (res == -1) {
>> +igt_info("Error:%s close popen file pointer fp error!\n", 
>> __func__);
>> +return 3;
>> +}
>> +retmsg[strlen(retmsg) - 1] = '\0';
>> +return 0;
>> +}
>> +}
>> +
>> +static int check_platform(void)
>> +{
>> +devid = intel_get_pci_device()->device_id;
>> +if (IS_BROADWELL(devid) || (IS_SKYLAKE(devid))) {
>> +return 0;
>> +} else {
>> +return 1;
>> +}
>> +}
>
>
>This is not future-proof. And it doesn't really tell whether the running kernel
>has GVT-g support enabled. Is it possible to detect GVT-g support here?
>
>
>> +
>> +static int check_tools(void)
>> +{
>> +if (system("which uuidgen") != 0) {
>> +return 1;
>> +} else if (system("which arp-scan") != 0) {
>> +return 2;
>> +}
>> +return 0;
>> +}
>> +
>> +static void create_guest(void)
>> +{
>> +char create_qcow_cmd[PATH_MAX] = {0};
>> +    char create_vgpu_cmd[PATH_MAX] = {0};
>> +char create_instance_cmd[PATH_MAX] = {0};
>> +
>> +sprintf(create_qcow_cmd, "qemu-img create -b %s -f qcow2 %s.qcow2",
>> +hda_path, hda_path);
>> +sprintf(create_vgpu_cmd, "echo \"%s\" >
>/sys/bus/pci/devices/:00:02.0/"
>> +   "mdev_supported_types/i915-GVTg_V4_1/create", uuid);
>> +sprintf(create_instance_cmd, "%s -m 2048 -smp 2 -M pc -name
>gvtg_guest"
>> +   " -hda %s.qcow2 -bios %s -enable-kvm --net nic,macaddr=%s -net"
>> +   " tap,script=/etc/qemu-ifup -vga none -device isa-vga -k en-us"
>> +   " -serial stdio -vnc :1 -machine kernel_irqchip=on -global"
>> +   " PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -cpu host"
>> +   " -usb -usbdevice tablet -device vfio-pci,sysfsdev="
>> +   "/sys/bus/pci/devices/:00:02.0/%s &",
>> +   qemu_path, hda_path, bios_path, mac_addr, uuid);
>> +igt_assert_eq(system(create_qcow_cmd), 0);
>> +igt_assert_eq(system(create_vgpu_cmd), 0);
>> +igt_assert_eq(system(create_instance_cmd), 0); }
>> +
>> +static void destroy_all_guest(void)
>> +{
>> +system("pkill qemu");
>> +}
>> +
>> +static void remove_vgpu(void)
>> +{
>> +char cmd[128] = {0};
>> +sprintf(cmd, "echo 1 >
>/sys/bus/pci/devices/:00:02.0/%s/remove", uuid);
>> +igt_assert_eq(system(cmd), 0);
>> +}
>
>Doesn't this echo need root?
[Xu, Terrence] Yes the root is needed for all our "echo" related commands, can 
I suppose the case is running under root privilege? Or need to return "skip" 
when it is not under root privilege?
>
>> +
>> +static void gen_mac_addr(void)
>> +{
>> +unsigned char mac_enum[16] = {'0', '1', '2', '3', '4', '5', '6',
>> +'7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'};
>> +unsigned short i, n = 2;
>> +srand(getpid());
>> +for (i = 2, n = 2; i < 15; i++, n++) {
>> +if (mac_addr[n] != ':') {
>> +mac_addr[n] = mac_enum[RANDOM(16)];
>> +}
>> +}
>> +}
>> +
>> +static void gen_uuid(void)
>> +{
>> +igt_assert_eq(super_system("uuidgen", uuid, sizeof(uuid)), 0); }
>> +
>> +static char *fetch_ip_by_mac(unsigned char *mac) {
>> +char cmd[1024] = {0};
>> +sprintf(cmd, "arp-scan

Re: [Intel-gfx] [PATCH i-g-t v2] Add the new tool for create GVT-g Linux guest based on KVMGT

2017-02-17 Thread Xu, Terrence

Does anyone has some comments? Thanks!

-Original Message-
From: Xu, Terrence 
Sent: Monday, February 6, 2017 12:10 PM
To: intel-gfx@lists.freedesktop.org
Cc: Wang, Zhenyu Z ; Sarvela, Tomi P 
; daniel.vet...@ffwll.ch; Lv, Zhiyuan 
; Jin, Gordon ; Xu, BenyuX 
; Wang, Hongbo ; Xu, Terrence 

Subject: RE: [Intel-gfx] [PATCH i-g-t v2] Add the new tool for create GVT-g 
Linux guest based on KVMGT

Does anyone has some comments? It is a IGT patch.

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Terrence Xu
Sent: Thursday, January 19, 2017 4:32 PM
To: intel-gfx@lists.freedesktop.org
Cc: Wang, Zhenyu Z ; Sarvela, Tomi P 
; daniel.vet...@ffwll.ch; Xu, Terrence 
; Lv, Zhiyuan ; Jin, Gordon 
; Xu, BenyuX ; Wang, Hongbo 

Subject: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest 
based on KVMGT

GVT-g (Intel® Graphics Virtualization Technology) is a full GPU virtualization 
solution with mediated pass-through support.

This tool is for create basic Linux guest based on KVMGT with VFIO framework, 
it including create vgpu, create guest, check IP address, destroy guest, remove 
vgpu,check dmesg log, etc functions.

v2: Treat this case as a free-standing tool, with detect & skip when it's not 
running on GVT-g capable platform or running without the required tools.

Signed-off-by: Terrence Xu 
Signed-off-by: Benyu Xu 
---
 tools/Makefile.sources  |   1 +
 tools/intel_gvtg_test.c | 355 
 2 files changed, 356 insertions(+)
 create mode 100644 tools/intel_gvtg_test.c

diff --git a/tools/Makefile.sources b/tools/Makefile.sources index 
e2451ea..05ef0b7 100644
--- a/tools/Makefile.sources
+++ b/tools/Makefile.sources
@@ -30,6 +30,7 @@ tools_prog_lists =\
intel_stepping  \
intel_watermark \
intel_gem_info  \
+intel_gvtg_test \
$(NULL)
 
 dist_bin_SCRIPTS = intel_gpu_abrt
diff --git a/tools/intel_gvtg_test.c b/tools/intel_gvtg_test.c new file mode 
100644 index 000..4c89800
--- /dev/null
+++ b/tools/intel_gvtg_test.c
@@ -0,0 +1,355 @@
+/*
+ * Copyright 2016 Intel Corporation
+ *   Terrence Xu 
+ *
+ * Permission is hereby granted, free of charge, to any person 
+obtaining a
+ * copy of this software and associated documentation files (the 
+"Software"),
+ * to deal in the Software without restriction, including without 
+limitation
+ * the rights to use, copy, modify, merge, publish, distribute, 
+sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom 
+the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be 
+included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
+EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
+MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 
+SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
+OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
+ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
+DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/*
+ * This program is intended for testing of validate GVT-g virtual 
+machine
+ * creation of allow for testing of KVMGT / XenGT.
+ *
+ * TODO:
+ * Enable more GVT-g related test cases.
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RANDOM(x) (rand() % x)
+
+static uint32_t devid;
+
+static unsigned char mac_addr[17] = {'0', '0', ':', '0', '0', ':',
+'0', '0', ':', '0', '0', ':', '0', '0', ':', '0', '0'}; static char 
+uuid[40]; static char guest_ip[32];
+
+static char qemu_path[PATH_MAX] = {0};
+static char hda_path[PATH_MAX] = {0};
+static char bios_path[PATH_MAX] = {0};
+
+static int super_system(const char *cmd, char *retmsg, int msg_len) {
+FILE *fp;
+int res = -1;
+if (cmd == NULL || retmsg == NULL || msg_len < 0) {
+igt_info("Error: %s system paramer invalid!\n", __func__);
+return 1;
+}
+fp = popen(cmd, "r");
+if (fp == NULL) {
+perror("popen");
+igt_info("Error: %s popen error: %s\n", __func__, strerror(errno));
+return 2;
+} else {
+memset(retmsg, 0, msg_len);
+while (fgets(

Re: [Intel-gfx] [PATCH i-g-t v2] Add the new tool for create GVT-g Linux guest based on KVMGT

2017-02-05 Thread Xu, Terrence

Does anyone has some comments? It is a IGT patch.

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Terrence Xu
Sent: Thursday, January 19, 2017 4:32 PM
To: intel-gfx@lists.freedesktop.org
Cc: Wang, Zhenyu Z ; Sarvela, Tomi P 
; daniel.vet...@ffwll.ch; Xu, Terrence 
; Lv, Zhiyuan ; Jin, Gordon 
; Xu, BenyuX ; Wang, Hongbo 

Subject: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest 
based on KVMGT

GVT-g (Intel® Graphics Virtualization Technology) is a full GPU virtualization 
solution with mediated pass-through support.

This tool is for create basic Linux guest based on KVMGT with VFIO framework, 
it including create vgpu, create guest, check IP address, destroy guest, remove 
vgpu,check dmesg log, etc functions.

v2: Treat this case as a free-standing tool, with detect & skip when it's not 
running on GVT-g capable platform or running without the required tools.

Signed-off-by: Terrence Xu 
Signed-off-by: Benyu Xu 
---
 tools/Makefile.sources  |   1 +
 tools/intel_gvtg_test.c | 355 
 2 files changed, 356 insertions(+)
 create mode 100644 tools/intel_gvtg_test.c

diff --git a/tools/Makefile.sources b/tools/Makefile.sources index 
e2451ea..05ef0b7 100644
--- a/tools/Makefile.sources
+++ b/tools/Makefile.sources
@@ -30,6 +30,7 @@ tools_prog_lists =\
intel_stepping  \
intel_watermark \
intel_gem_info  \
+intel_gvtg_test \
$(NULL)
 
 dist_bin_SCRIPTS = intel_gpu_abrt
diff --git a/tools/intel_gvtg_test.c b/tools/intel_gvtg_test.c new file mode 
100644 index 000..4c89800
--- /dev/null
+++ b/tools/intel_gvtg_test.c
@@ -0,0 +1,355 @@
+/*
+ * Copyright 2016 Intel Corporation
+ *   Terrence Xu 
+ *
+ * Permission is hereby granted, free of charge, to any person 
+obtaining a
+ * copy of this software and associated documentation files (the 
+"Software"),
+ * to deal in the Software without restriction, including without 
+limitation
+ * the rights to use, copy, modify, merge, publish, distribute, 
+sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom 
+the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be 
+included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
+EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
+MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 
+SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
+OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
+ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
+DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/*
+ * This program is intended for testing of validate GVT-g virtual 
+machine
+ * creation of allow for testing of KVMGT / XenGT.
+ *
+ * TODO:
+ * Enable more GVT-g related test cases.
+ */
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RANDOM(x) (rand() % x)
+
+static uint32_t devid;
+
+static unsigned char mac_addr[17] = {'0', '0', ':', '0', '0', ':',
+'0', '0', ':', '0', '0', ':', '0', '0', ':', '0', '0'}; static char 
+uuid[40]; static char guest_ip[32];
+
+static char qemu_path[PATH_MAX] = {0};
+static char hda_path[PATH_MAX] = {0};
+static char bios_path[PATH_MAX] = {0};
+
+static int super_system(const char *cmd, char *retmsg, int msg_len) {
+FILE *fp;
+int res = -1;
+if (cmd == NULL || retmsg == NULL || msg_len < 0) {
+igt_info("Error: %s system paramer invalid!\n", __func__);
+return 1;
+}
+fp = popen(cmd, "r");
+if (fp == NULL) {
+perror("popen");
+igt_info("Error: %s popen error: %s\n", __func__, strerror(errno));
+return 2;
+} else {
+memset(retmsg, 0, msg_len);
+while (fgets(retmsg, msg_len, fp)) {
+;
+};
+res = pclose(fp);
+if (res == -1) {
+igt_info("Error:%s close popen file pointer fp error!\n", 
__func__);
+return 3;
+}
+retmsg[strlen(retmsg) - 1] = '\0';
+return 0;
+}
+}
+
+static int check_platform(void)
+{
+devid = intel_get_pci_device()->device_id;
+if (IS_BRO

Re: [Intel-gfx] [PATCH igt] Add the new case for create GVT-g Linux guest based on KVMGT

2017-01-01 Thread Xu, Terrence

\n", __func__, strerror(errno));
> > +return 2;
> > +} else {
> > +memset(retmsg, 0, msg_len);
> > +while (fgets(retmsg, msg_len, fp)) {
> > +;
> > +};
> > +res = pclose(fp);
> > +if (res == -1) {
> > +igt_info("Error:%s close popen file pointer fp error!\n", 
> > __func__);
> > +return 3;
> > +}
> > +retmsg[strlen(retmsg) - 1] = '\0';
> > +return 0;
> > +}
> > +}
> > +
> > +static void create_guest(void)
> > +{
> > +char create_qcow_cmd[PATH_MAX] = {0};
> > +char create_vgpu_cmd[PATH_MAX] = {0};
> > +char create_instance_cmd[PATH_MAX] = {0};
> > +
> > +sprintf(create_qcow_cmd, "qemu-img create -b %s -f qcow2 %s.qcow2",
> > +hda_path, hda_path);
> > +sprintf(create_vgpu_cmd, "echo \"%s\" >
> /sys/bus/pci/devices/:00:02.0/"
> > +   "mdev_supported_types/i915-GVTg_V4_1/create", uuid);
> > +sprintf(create_instance_cmd, "%s -m 2048 -smp 2 -M pc -name
> gvtg_guest"
> > +   " -hda %s.qcow2 -bios %s -enable-kvm --net nic,macaddr=%s -net"
> > +   " tap,script=/etc/qemu-ifup -vga none -device isa-vga -k en-us"
> > +   " -serial stdio -vnc :1 -machine kernel_irqchip=on -global"
> > +   " PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -cpu host"
> > +   " -usb -usbdevice tablet -device vfio-pci,sysfsdev="
> > +   "/sys/bus/pci/devices/:00:02.0/%s &",
> > +   qemu_path, hda_path, bios_path, mac_addr, uuid);
> > +system(create_qcow_cmd);
> > +system(create_vgpu_cmd);
> > +system(create_instance_cmd);
> > +}
> > +
> > +static void destroy_all_guest(void)
> > +{
> > +system("pkill qemu");
> > +}
> > +
> > +static void remove_vgpu(void)
> > +{
> > +char cmd[128] = {0};
> > +sprintf(cmd, "echo 1 > /sys/bus/pci/devices/:00:02.0/%s/remove",
> uuid);
> > +system(cmd);
> > +}
> > +
> > +static void gen_mac_addr(void)
> > +{
> > +unsigned char mac_enum[16] = {'0', '1', '2', '3', '4', '5', '6',
> > +'7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'};
> > +unsigned short i, n = 2;
> > +srand(getpid());
> > +for (i = 2, n = 2; i < 15; i++, n++) {
> > +if (mac_addr[n] != ':') {
> > +mac_addr[n] = mac_enum[RANDOM(16)];
> > +}
> > +}
> > +}
> > +
> > +static void gen_uuid(void)
> > +{
> > +super_system("uuidgen", uuid, sizeof(uuid)); }
> > +
> > +static char *fetch_ip_by_mac(unsigned char *mac) {
> > +char cmd[1024] = {0};
> > +sprintf(cmd, "arp-scan -l -I $(ip addr show|grep inet|grep global|"
> > +"awk '{print $NF;}')|grep -i %s|awk '{print $1}'", mac);
> > +super_system(cmd, guest_ip, sizeof(guest_ip));
> > +return guest_ip;
> > +}
> > +
> > +static int check_guest_ip(void)
> > +{
> > +int timeout = 0;
> > +while (timeout <= 12) {
> > +igt_info("Try to connnect guest,the %d time.\n", timeout);
> > +if (timeout == 12) {
> > +igt_info("Cannot connect to guest.\n");
> > +return 1;
> > +break;
> > +}
> > +
> > +fetch_ip_by_mac(mac_addr);
> > +
> > +if (guest_ip[0] != '\0') {
> > +igt_info("Fetched guest ip address: %s.\n", guest_ip);
> > +break;
> > +}
> > +timeout++;
> > +sleep(5);
> > +}
> > +return 0;
> > +}
> > +
> > +static void clear_dmesg(void)
> > +{
> > +system("dmesg -c");
> > +}
> > +
> > +static int check_dmesg(void)
> > +{
> > +char errorlog[PATH_MAX] = {0};
> > +
> > +super_system("dmesg|grep -E \"GPU HANG|gfx reset|BUG\"", errorlog,
> > +sizeof(errorlog));
> > +
> > +if (errorlog[0] == '\0') {
> > +return 0;
> > +} else {
> > +return

Re: [Intel-gfx] [PATCH v5 00/10] Enhance vfio PCI hot reset for vfio cdev device

Re: [Intel-gfx] [PATCH v11 00/23] Add vfio_device cdev for iommufd support

Re: [Intel-gfx] [PATCH v2 00/10] Introduce new methods for verifying ownership in vfio PCI hot reset

Re: [Intel-gfx] [PATCH v2 00/10] Introduce new methods for verifying ownership in vfio PCI hot reset

Re: [Intel-gfx] [PATCH v7 00/22] Add vfio_device cdev for iommufd support

Re: [Intel-gfx] [PATCH v2 0/5] vfio: Make emulated devices prepared for vfio device cdev

Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support

Re: [Intel-gfx] [PATCH v4 00/10] cover-letter: Update vfio_pin/unpin_pages API

Re: [Intel-gfx] [RFT][PATCH v2 0/9] Update vfio_pin/unpin_pages API

Re: [Intel-gfx] Various problems for the Xen for XenGT code and guide.

Re: [Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q3 release of KVMGT (Intel GVT-g for KVM)

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q3 release of XenGT (Intel GVT-g for Xen)

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q3 release of KVMGT (Intel GVT-g for KVM)

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q1 release of XenGT (Intel GVT-g for Xen)

[Intel-gfx] [GVT-g] [ANNOUNCE] 2018-Q1 release of KVMGT (Intel GVT-g for KVM)

[Intel-gfx] [GVT-g] [ANNOUNCE] 2017-Q3 release of XenGT (Intel GVT-g for Xen)

[Intel-gfx] [GVT-g] [ANNOUNCE] 2017-Q3 release of KVMGT (Intel GVT-g for KVM)

[Intel-gfx] [GVT-g] [ANNOUNCE] 2017-Q2 release of KVMGT (Intel GVT-g for KVM)

[Intel-gfx] [GVT-g] [ANNOUNCE] 2017-Q2 release of XenGT (Intel GVT-g for Xen)

Re: [Intel-gfx] [PATCH] drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly

Re: [Intel-gfx] [PATCH i-g-t v3] Add the new tool for create GVT-g Linux guest based on KVMGT

Re: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest based on KVMGT

Re: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest based on KVMGT

Re: [Intel-gfx] [PATCH i-g-t v2] Add the new tool for create GVT-g Linux guest based on KVMGT

Re: [Intel-gfx] [PATCH i-g-t v2] Add the new tool for create GVT-g Linux guest based on KVMGT

Re: [Intel-gfx] [PATCH igt] Add the new case for create GVT-g Linux guest based on KVMGT

26 matches

Site Navigation

Mail list logo

Footer information