Re: [iGVT-g] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM
by Jike Song
Hi all,
We are pleased to announce another update of Intel GVT-g for KVM.
Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. KVM is supported by Intel GVT-g(a.k.a. KVMGT).
Repositories
Kernel: https://github.com/01org/igvtg-kernel (2015q3-3.18.0 branch)
Qemu: https://github.com/01org/igvtg-qemu (kvmgt_public2015q3 branch)
This update consists of:
- KVMGT is now merged with XenGT in unified repositories(kernel and qemu), but currently
different branches for qemu. KVMGT and XenGT share same iGVT-g core logic.
- PPGTT supported, hence the Windows guest support
- KVMGT now supports both 4th generation (Haswell) and 5th generation (Broadwell) Intel Core(TM) processors
- 2D/3D/Media decoding have been validated on Ubuntu 14.04 and Windows7/Windows 8.1
Next update will be around early Jan, 2016.
Known issues:
- At least 2GB memory is suggested for VM to run most 3D workloads.
- 3Dmark06 running in Windows VM may have some stability issue.
- Using VLC to play .ogg file may cause mosaic or slow response.
Please subscribe the mailing list to report BUGs, discuss, and/or contribute:
https://lists.01.org/mailman/listinfo/igvt-g
More information about Intel GVT-g background, architecture, etc can be found at(may not be up-to-date):
https://01.org/igvt-g
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,
Jike
On 12/04/2014 10:24 AM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce the first release of KVMGT project. KVMGT is the implementation of Intel GVT-g technology, a full GPU virtualization solution. Under Intel GVT-g, a virtual 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 of performance, feature, and sharing capability.
>
>
> KVMGT is still in the early stage:
>
> - Basic functions of full GPU virtualization works, guest can see a full-featured vGPU.
> We ran several 3D workloads such as lightsmark, nexuiz, urbanterror and warsow.
>
> - Only Linux guest supported so far, and PPGTT must be disabled in guest through a
> kernel parameter(see README.kvmgt in QEMU).
>
> - This drop also includes some Xen specific changes, which will be cleaned up later.
>
> - Our end goal is to upstream both XenGT and KVMGT, which shares ~90% logic for vGPU
> device model (will be part of i915 driver), with only difference in hypervisor
> specific services
>
> - insufficient test coverage, so please bear with stability issues :)
>
>
>
> There are things need to be improved, esp. the KVM interfacing part:
>
> 1 a domid was added to each KVMGT guest
>
> An ID is needed for foreground OS switching, e.g.
>
> # echo <domid> > /sys/kernel/vgt/control/foreground_vm
>
> domid 0 is reserved for host OS.
>
>
> 2 SRCU workarounds.
>
> Some KVM functions, such as:
>
> kvm_io_bus_register_dev
> install_new_memslots
>
> must be called *without* &kvm->srcu read-locked. Otherwise it hangs.
>
> In KVMGT, we need to register an iodev only *after* BAR registers are
> written by guest. That means, we already have &kvm->srcu hold -
> trapping/emulating PIO(BAR registers) makes us in such a condition.
> That will make kvm_io_bus_register_dev hangs.
>
> Currently we have to disable rcu_assign_pointer() in such functions.
>
> These were dirty workarounds, your suggestions are high welcome!
>
>
> 3 syscalls were called to access "/dev/mem" from kernel
>
> An in-kernel memslot was added for aperture, but using syscalls like
> open and mmap to open and access the character device "/dev/mem",
> for pass-through.
>
>
>
>
> The source codes(kernel, qemu as well as seabios) are available at github:
>
> git://github.com/01org/KVMGT-kernel
> git://github.com/01org/KVMGT-qemu
> git://github.com/01org/KVMGT-seabios
>
> In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred.
>
>
>
> More information about Intel GVT-g and KVMGT can be found at:
>
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
> http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Ful...
>
>
> Appreciate your comments, BUG reports, and contributions!
>
>
>
>
> --
> Thanks,
> Jike
>
4 years, 7 months
Re: [iGVT-g] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
by Jike Song
Hi all,
We are pleased to announce another update of Intel GVT-g for Xen.
Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Xen is currently supported on Intel Processor Graphics (a.k.a. XenGT); and the core logic can be easily ported to other hypervisors.
Repositories
Kernel: https://github.com/01org/igvtg-kernel (2015q3-3.18.0 branch)
Xen: https://github.com/01org/igvtg-xen (2015q3-4.5 branch)
Qemu: https://github.com/01org/igvtg-qemu (xengt_public2015q3 branch)
This update consists of:
- XenGT is now merged with KVMGT in unified repositories(kernel and qemu), but currently
different branches for qemu. XenGT and KVMGT share same iGVT-g core logic.
- fix sysfs/debugfs access seldom crash issue
- fix a BUG in XenGT I/O emulation logic
- improve 3d workload stability
Next update will be around early Jan, 2016.
Known issues:
- At least 2GB memory is suggested for VM to run most 3D workloads.
- Keymap might be incorrect in guest. Config file may need to explicitly specify "keymap='en-us'". Although it looks like the default value, earlier we saw the problem of wrong keymap code if it is not explicitly set.
- When using three monitors, doing hotplug between Guest pause/unpause may not be able to lightup all monitors automatically. Some specific monitor issues.
- Cannot move mouse pointer smoothly in guest by default launched by VNC mode. Configuration file need to explicitly specify "usb=1" to enable a USB bus, and "usbdevice='tablet'" to add pointer device using absolute coordinates.
- Resume dom0 from S3 may cause some error message.
- i915 unload/reload cannot works well with less than 3 vcpu when upowerd service was running
- Unigen Tropics running in multiple guests will cause dom0 and guests tdr.
Please subscribe the mailing list to report BUGs, discuss, and/or contribute:
https://lists.01.org/mailman/listinfo/igvt-g
More information about Intel GVT-g background, architecture, etc can be found at(may not be up-to-date):
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%20S...
http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20S...
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,
Jike
On 07/07/2015 10:49 AM, Jike Song wrote:
> Hi all,
>
> We're pleased to announce a public update to Intel Graphics Virtualization Technology(Intel GVT-g, formerly known as XenGT).
>
> Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Xen is currently supported on Intel Processor Graphics (a.k.a. XenGT); and the core logic can be easily ported to other hypervisors, for example, the experimental code has been released to support GVT-g running on a KVM hypervisor (a.k.a KVMGT).
>
> Tip of repositories
> -------------------------
>
> Kernel: 5b73653d5ca, Branch: master-2015Q2-3.18.0
> Qemu: 2a75bbff62c1, Branch: master
> Xen: 38c36f0f511b1, Branch: master-2015Q2-4.5
>
> This update consists of:
> - Change time based scheduler timer to be configurable to enhance stability
> - Fix stability issues that VM/Dom0 got tdr when hang up at some specific instruction on BDW
> - Optimize the emulation of el_status register to enhance stability
> - 2D/3D performance in linux VMs has been improved about 50% on BDW
> - Fix abnormal idle power consumption issue due to wrong forcewake policy
> - Fix tdr issue when running 2D/3D/Media workloads in Windows VMs simultaneously
> - KVM support is still in a separate branch as prototype work. We plan to integrate KVM/Xen support together in the future releases
> - Next update will be around early Oct, 2015
>
> Notice that this release can support both Intel 4th generation Core CPU(code name: Haswell) and Intel 5th generation Core CPU (code name: Broadwell), while the limitation of the latter include:
> * 3D conformance may have some failure
> * Under high demand 3D workloads, stability issues are detected
> * Multi-monitor scenario is not fully tested, while single monitor of VGA/HDMI/DP/eDP should just work
> * Hotplug DP may cause black screen even on native environment
>
> Where to get
>
> kernel: https://github.com/01org/XenGT-Preview-kernel.git
> xen: https://github.com/01org/XenGT-Preview-xen.git
> qemu: https://github.com/01org/XenGT-Preview-qemu.git
>
>
> We have a mailing list for GVT-g development, bug report and technical discussion:
>
> https://lists.01.org/mailman/listinfo/igvt-g
>
> More information about Intel GVT-g background, architecture, etc can be found at:
>
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
> http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20S...
> 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,
> Jike
>
> On 04/10/2015 09:23 PM, Jike Song wrote:
>> Hi all,
>>
>> We're pleased to announce a public update to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A 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. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors.
>>
>> Tip of repositories
>> -------------------------
>>
>> Kernel: a011c9f953e, Branch: master-2015Q1-3.18.0
>> Qemu: 2a75bbff62c1, Branch: master
>> Xen: 38c36f0f511b1, Branch: master-2015Q1-4.5
>>
>> Summary this update
>> -------------------------
>> - Preliminary Broadwell support.
>> - kernel update from drm-intel 3.17.0 to drm-intel 3.18.0(tag: drm-intel-next-fixes-2014-12-17, notice that i915 driver code is much newer than kernel stable version).
>> - Next update will be around early July, 2015.
>> - KVM support is still in a separate branch as prototype work. We plan to integrate KVM/Xen support together in future releases.
>>
>> This update consists of:
>> - gvt-g core logic code was moved into i915 driver directory.
>> - Host mediation is used for dom0 i915 driver access, instead of de-privileged dom0.
>> - The Xen-specific code was separated from vgt core logic into a new file "driver/xen/xengt.c".
>> - Broadwell is preliminarily supported in this release. Users could start multiple linux/windows 64-bit virtual machines simultaneously, and perform display switch among them.
>>
>> Notice that it is still preliminary release for BDW, which is not yet in the same level of HSW release. Differences include:
>> * Power/performance tuning on BDW is not yet done.
>> * Stability needs to be improved.
>> * No 32-bit guest OS support.
>> * Multi-monitor scenario is not fully tested, while single monitor of VGA/HDMI/DP/eDP should just work.
>>
>>
>> Where to get:
>> -----------------
>> kerenl: https://github.com/01org/XenGT-Preview-kernel.git
>> Xen: https://github.com/01org/XenGT-Preview-xen.git
>> Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>>
>> Please refer to the new setup guide, which provides step-to-step details about building/configuring/running Intel GVT-g:
>> https://github.com/01org/XenGT-Preview-kernel/blob/master-2015Q1-3.18.0/X...
>>
>> More information about Intel GVT-g background, architecture, etc can be found at:
>> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
>> http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20S...
>> https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>>
>> The previous update can be found here:
>> http://lists.xen.org/archives/html/xen-devel/2014-12/msg00474.html
>>
>>
>> Note
>> ---------------
>> The XenGT project should be considered a work in progress, As such it is not a complete product nor should it be considered one., Extra care should be taken when testing and configuring a system to use the XenGT project.
>>
>>
>> --
>> Thanks,
>> Jike
>>
>> On 01/09/2015 04:51 PM, Jike Song wrote:
>>> Hi all,
>>>
>>> We're pleased to announce a public update to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A 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. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors. 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.
>>>
>>> The news of this update:
>>>
>>> - kernel update from 3.14.1 to drm-intel 3.17.0.
>>> - We plan to integrate Intel GVT-g as a feature in i915 driver. That effort is still under review, not included in this update yet.
>>> - Next update will be around early Apr, 2015.
>>>
>>> This update consists of:
>>>
>>> - Including some bug fixes and stability enhancement.
>>> - Making XenGT device model to be aware of Broadwell. In this version BDW is not yet functioning.
>>> - Available Fence registers number is changed to 32 from 16 to align with HSW hardware.
>>> - New cascade interrupt framework for supporting interrupt virtualization on both Haswell and Broadwell.
>>> - Add back the gem_vgtbuffer. The previous release did not build that module for 3.14 kernel. In this release, the module is back and rebased to 3.17.
>>> - Enable the irq based context switch in vgt driver, which will help reduce the cpu utilization while doing context switch, it is enabled by default, and can be turn off by kernel flag irq_based_ctx_switch.
>>>
>>>
>>> Please refer to the new setup guide, which provides step-to-step details about building/configuring/running Intel GVT-g:
>>>
>>> https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Gui...
>>>
>>> The new source codes are available at the updated github repos:
>>>
>>> Linux: https://github.com/01org/XenGT-Preview-kernel.git
>>> Xen: https://github.com/01org/XenGT-Preview-xen.git
>>> Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>>>
>>>
>>> More information about Intel GVT-g background, architecture, etc can be found at:
>>>
>>>
>>> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
>>> http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20S...
>>> https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>>>
>>>
>>>
>>> The previous update can be found here:
>>>
>>>
>>> http://lists.xen.org/archives/html/xen-devel/2014-12/msg00474.html
>>>
>>>
>>>
>>> Appreciate your comments!
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Jike
>>>
>>>
>>> On 12/04/2014 10:45 AM, Jike Song wrote:
>>>> Hi all,
>>>>
>>>> We're pleased to announce a public release to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors.
>>>>
>>>>
>>>> The news of this update:
>>>>
>>>>
>>>> - kernel update from 3.11.6 to 3.14.1
>>>>
>>>> - We plan to integrate Intel GVT-g as a feature in i915 driver. That effort is still under review, not included in this update yet
>>>>
>>>> - Next update will be around early Jan, 2015
>>>>
>>>>
>>>> This update consists of:
>>>>
>>>> - Windows HVM support with driver version 15.33.3910
>>>>
>>>> - Stability fixes, e.g. stabilize GPU, the GPU hang occurrence rate becomes rare now
>>>>
>>>> - Hardware Media Acceleration for Decoding/Encoding/Transcoding, VC1, H264 etc. format supporting
>>>>
>>>> - Display enhancements, e.g. DP type is supported for virtual PORT
>>>>
>>>> - Display port capability virtualization: with this feature, dom0 manager could freely assign virtual DDI ports to VM, not necessary to check whether the corresponding physical DDI ports are available
>>>>
>>>>
>>>>
>>>> Please refer to the new setup guide, which provides step-to-step details about building/configuring/running Intel GVT-g:
>>>>
>>>>
>>>> https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Gui...
>>>>
>>>>
>>>>
>>>> The new source codes are available at the updated github repos:
>>>>
>>>>
>>>> Linux: https://github.com/01org/XenGT-Preview-kernel.git
>>>>
>>>> Xen: https://github.com/01org/XenGT-Preview-xen.git
>>>>
>>>> Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>>>>
>>>>
>>>> More information about Intel GVT-g background, architecture, etc can be found at:
>>>>
>>>>
>>>> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
>>>>
>>>> http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20S...
>>>>
>>>> https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>>>>
>>>>
>>>> The previous update can be found here:
>>>>
>>>>
>>>> http://lists.xen.org/archives/html/xen-devel/2014-07/msg03248.html
>>>>
>>>>
>>>> Appreciate your comments!
>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Jike
>>>>
>>>> On 07/25/2014 04:31 PM, Jike Song wrote:
>>>>> Hi all,
>>>>>
>>>>> We're pleased to announce an update to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A 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. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors.
>>>>>
>>>>> The news of this update:
>>>>>
>>>>> - Project code name is "XenGT", now official name is Intel Graphics Virtualization Technology (Intel GVT-g)
>>>>> - Currently Intel GVT-g supports Intel Processor Graphics built into 4th generation Intel Core processors - Haswell platform
>>>>> - Moving forward, XenGT will change to quarterly release cadence. Next update will be around early October, 2014.
>>>>>
>>>>> This update consists of:
>>>>>
>>>>> - Stability fixes, e.g. stable DP support
>>>>> - Display enhancements, e.g. virtual monitor support. Users can define a virtual monitor type with customized EDID for virtual machines, not necessarily the same as physical monitors.
>>>>> - Improved support for GPU recovery
>>>>> - Experimental Windows HVM support. To download the experimental version, see setup guide for details
>>>>> - Experimental Hardware Media Acceleration for decoding.
>>>>>
>>>>>
>>>>> Please refer to the new setup guide, which provides step-to-step details about building/configuring/running Intel GVT-g:
>>>>>
>>>>> https://github.com/01org/XenGT-Preview-kernel/blob/master/XenGT_Setup_Gui...
>>>>>
>>>>>
>>>>> The new source codes are available at the updated github repos:
>>>>>
>>>>> Linux: https://github.com/01org/XenGT-Preview-kernel.git
>>>>> Xen: https://github.com/01org/XenGT-Preview-xen.git
>>>>> Qemu: https://github.com/01org/XenGT-Preview-qemu.git
>>>>>
>>>>>
>>>>> More information about Intel GVT-g background, architecture, etc can be found at:
>>>>>
>>>>> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
>>>>> http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20S...
>>>>> https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
>>>>>
>>>>> The previous update can be found here:
>>>>>
>>>>> http://lists.xen.org/archives/html/xen-devel/2014-02/msg01848.html
>>>>>
>>>>> Appreciate your comments!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> Jike
>>>>>
4 years, 7 months
Porting to another hypervisor
by Brad Bozarth
Hi,
I'm exploring i-gvt as a way to potentially support 3D acceleration in
another hypervisor. In this git issue (
https://github.com/01org/XenGT-Preview-xen/issues/6) Jike says "if the Host
OS is not Linux, the i915/vgt drivers adoption may have more effort
needed." ... What does this mean? Would the Intel supplied i915 drivers on
a Windows host allow a hypervisor there to support gvt VMs, assuming the
MPT services were ported to that hypervisor?
Thank you!
Brad
5 years, 2 months
License
by Brad Bozarth
In the KVMGT slides I read from 2014, it said "vGT device model is GPL/MIT
dual-licensed and VMM agnostic" .. In the top of, for example, vga-vgt.c in
the git repo, it says GPL. Is that code (like much of the original QEMU
display code) actually also licensed MIT? What code is MIT licensed and how
could I tell?
Thanks,
Brad
5 years, 3 months
some guest installation in XenGT
by o烟花易冷ヤ
hi
when i install ubuntu14.04 (Guest) in XenGT, we got an 'installation failed ' message. Then we checked our ISO, and found that it is correct. we always can not install the Guest successfully. Does anyone had the same problem? i need some help
message:
The installer encountered an error copying files to the hard disk:
[error 5] Input/output error:'/target/usr/share/im-config/data'
This is often due to a faulty hard disk . it may help to check whether the hard disk is old and in need of replacement,
or to move the system to a cooler environment.
thanks
Xiaofei He
5 years, 3 months
some guest installation in XenGT
by o烟花易冷ヤ
hi
when i install ubuntu14.04 (Guest) in XenGT, we got an 'installation failed ' message. Then we checked our ISO, and found that it is correct. we always can not install the Guest successfully. Does anyone had the same problem?
message:
The installer encountered an error copying files to the hard disk:
[error 5] Input/output error:'/target/usr/share/im-config/data'
This is often due to a faulty hard disk . it may help to check whether the hard disk is old and in need of replacement,
or to move the system to a cooler environment.
thanks
Xiaofei He
5 years, 3 months
[PATCH v4 0/8] igd passthrough chipset tweaks
by Gerd Hoffmann
Hi,
Next version of the patches, after a longish break.
Meanwhile it is more clear how we are going to handle the igd
passthrough quirks with kvm: vfio will get support for device-specific
regions, and we will use that for the opregion and also to provide
unpriviledged read access to host bridge (00:00.0) and isa bridge
(00:1f,0) pci config space.
That implies we wouldn't share the code for pci config space access
and the existing xen code wouldn't be reused for kvm, except maybe for
the struct IGDHostInfo tables.
Separating out the igd support code into its own file and the cleanups +
bugfixes on top of that still make sense though. So here we go with a
stripped down patch series ...
cheers,
Gerd
Gerd Hoffmann (8):
pc: remove has_igd_gfx_passthru global
pc: move igd support code to igd.c
igd: switch TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE to realize
igd: TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE: call parent realize
igd: use defines for standard pci config space offsets
igd: revamp host config read
igd: move igd-passthrough-isa-bridge to igd.c too
igd: handle igd-passthrough-isa-bridge setup in realize()
default-configs/x86_64-softmmu.mak | 1 +
hw/i386/pc_piix.c | 115 +--------------------------
hw/pci-host/Makefile.objs | 3 +
hw/pci-host/igd.c | 157 +++++++++++++++++++++++++++++++++++++
hw/pci-host/piix.c | 90 ---------------------
hw/xen/xen_pt.c | 4 +-
hw/xen/xen_pt.h | 5 +-
include/hw/i386/pc.h | 2 +-
vl.c | 10 ---
9 files changed, 167 insertions(+), 220 deletions(-)
create mode 100644 hw/pci-host/igd.c
--
1.8.3.1
5 years, 3 months
Ask for comments of getting guest framebuffer in igvt-g
by Zhiyuan Lv
Dear i915 developers,
Here I have one topic hoping to get your comments and suggestions.
Basically it is about graphics virtualization(igvt-g), for the purpose
of host system to get virtual machine's framebuffer. We would like to
hear your opinions about some design opens. Below is the
patch and some more detailed description. We appreciate your time
on that, and thanks in advance for any comments!
https://patchwork.freedesktop.org/patch/71852/
When people try igvt-g, one common question we heard is how to get
guest VM's framebuffer. It is for various purposes:
- A compositor in host (it can be QEMU itself or other viewer
applications) can use the contents to render a window in host;
- Remote protocol can easily handle it to support 3D/Media
accelerated VMs;
The specific requirements include:
- Be able to map the guest framebuffer so that host CPU can read it;
- Be able to export guest framebuffer through dam_buf;
- Be able to direct render with guest framebuffers;
In order to support that, we introduced a new gem object called
gvtbuffer. It is a special object with guest framebuffer's pages as
its backing storage. Meanwhile, it could behave normally like other
gem objects. It can be mapped, exported and used by EGL APIs.
Although we say guest fb pages for gvtbuffer, the solution itself is
safe. Because gvtbuffer gets entries from physical GGTT which cannot
be accessed by guest VM directly. igvt-g device model is responsible
for filling physical GGTT after translating the iova from guest GGTT
table. Even if a malicious guest uses a bad framebuffer, the pages
filled in GGTT are always valid. Then when gvtbuffer tries to get some
entries, they are always valid address not causing hardware problems.
It is possible, however, that the guest VM performs page flip while
gvtbuffer is attached with the framebuffer, and is being used for
rendering. That may cause some tearing in theory. But in practice, we
did not see that. If that is a concern, we can consider to delay the
VBLANK irq injection to guest as a solution.
So in general, do you think it is OK to introduce the gvtbuffer gem
object, or there could be better way to handle it in gem framework?
Currently we have a new IOCTL added for the gvtbuffer, and we also
added some data structures to describe the framebuffer format for user
mode. Do you think that is fine? Thanks again!
Regards,
-Zhiyuan
5 years, 3 months
Re: [iGVT-g] [PATCH v2] vfio/igd: handle q35 machine type
by Gerd Hoffmann
Hi,
[ context for igvt list: how do we deal with the ich9 lpc emulated by
q35 machine type best, when pci-assigning a igd? ]
> > It seems
> > quite limiting of igd assignment on q35 VMs if we're going to remove
> > collateral device modification. Should we only claim "legacy" igd
> > support on 440FX and support only universal passthrough on q35? Thanks,
>
> I'll go test this a bit more. Possibly we can drop the whole lpc
> tweaking. At least when looking at the linux driver code it doesn't
> seem to be very important.
Ok, we can't, it's actually checked in quite a few places. The checks
are hidden in a macro though which I initially didn't spot. The bios is
unhappy too if the lpc @ 1f.0 goes away.
But just copying over the pci ids doesn't work either, it breaks
firmware q35 initialization. Which in turn breaks acpi (partly), so
some things like poweroff stop working. And I have some irq routing
errors in the kernel log too.
So, q35 works (without lpc tweaks) with 4.5-rc6+ guest kernel (should be
4.4.5+ soon) and bios rom disabled. That is at least a start.
To get the bios and older kernels working we have to fiddle with the
lpc. Copying from the host looks bad to me, we have to maintain tons of
pci ids in the firmware then. At least the intel driver only needs to
know which pch generation is used, so we might be able to get away with
one pch per igd generation, and hopefully can stop doing that long term,
when intel untangles igd and pch in hardware.
cheers,
Gerd
5 years, 3 months
