[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Status IGD pass-through with QEMU/KVM

From: Jan Kiszka
Subject: Re: [Qemu-devel] Status IGD pass-through with QEMU/KVM
Date: Tue, 10 Feb 2015 08:36:10 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2015-01-28 16:43, Jan Kiszka wrote:
> On 2015-01-28 16:36, Alex Williamson wrote:
>> On Wed, 2015-01-28 at 16:02 +0100, Jan Kiszka wrote:
>>> Hi Alex,
>>> before getting dirty fingers in vain: what is the current status of
>>> handing an IGD GPU to a KVM guest, specifically Windows? I found some
>>> related QEMU patches from last year on the list, but it seems they
>>> didn't progress. Are there open issues without known solutions or is it
>>> "just" about putting pieces together - given that there related patches
>>> for Xen floating around?
>> Hi Jan,
>> The patches submitted last year by Andrew Barnes are functional (AFAIK),
>> but mostly proof-of-concept quality.  They make use of /dev/mem in place
>> of designing VFIO interfaces, they hack into various chipset code, etc.
>> Based on the attempts to port the Xen IGD code into QEMU, I think Intel
>> was working on reducing the machine level impact of IGD assignment with
>> a "universal" driver, but I haven't seen any status updates on that for
>> some time.  If Intel is successful in creating such a driver, then IGD
>> assignment may be no more complicated that discrete assignment (but
>> might only support very new HW).  To support current hardware and
>> drivers, we need to expose not only the IGD device, but manipulate
>> chispet device IDs and punch through registers and opregions on other
>> devices.  Andrew's patches do this, but need help to architect
>> interfaces and break down the code into upstream-able chunks.  Thanks,
> OK, thanks. Need to study more details then.

Did so by now, with rather unsatisfying results:

I tried to reproduce the setup Andrew once described, including
identical kernel and seabios. However, starting a guest on a H87I-PLUS
Asus board didn't get me far. The screen remained black, the guest
seemed stuck in the BIOS (didn't check where exactly). I'm either
missing a step or the hacks are still too fragile and break on my setup.

In contrast, running Xen 4.4.1, as it falls out of an OpenSUSE 13.2
installation, on the very same board provided direct success. Linux and
Windows were able to use the GPU, early VGA output included. On Windows
I was able to install the Asus-provided Intel drivers flawlessly (didn't
try i915 under Linux intensively, just the framebuffer console).

Any ideas what could be still a problem? Also CC'ing Andrew - any news
on your side?


Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

reply via email to

[Prev in Thread] Current Thread [Next in Thread]