From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGUfT-0008U1-SC for qemu-devel@nongnu.org; Wed, 28 Jan 2015 10:36:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGUfO-0005Vx-Mp for qemu-devel@nongnu.org; Wed, 28 Jan 2015 10:36:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGUfO-0005Vn-Fc for qemu-devel@nongnu.org; Wed, 28 Jan 2015 10:36:30 -0500 Message-ID: <1422459387.22865.105.camel@redhat.com> From: Alex Williamson Date: Wed, 28 Jan 2015 08:36:27 -0700 In-Reply-To: <54C8FA00.2060707@siemens.com> References: <54C8FA00.2060707@siemens.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Status IGD pass-through with QEMU/KVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , kvm 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, Alex