From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm <kvm@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org>,
Andrew Barnes <umbramalison@gmail.com>
Subject: Re: Status IGD pass-through with QEMU/KVM
Date: Tue, 10 Feb 2015 08:36:10 +0100 [thread overview]
Message-ID: <54D9B4EA.9050009@siemens.com> (raw)
In-Reply-To: <54C903B3.8070104@siemens.com>
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?
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
prev parent reply other threads:[~2015-02-10 7:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 15:02 Status IGD pass-through with QEMU/KVM Jan Kiszka
2015-01-28 15:36 ` Alex Williamson
2015-01-28 15:43 ` Jan Kiszka
2015-02-10 7:36 ` Jan Kiszka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D9B4EA.9050009@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=umbramalison@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox