From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42598) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGUmY-0005l8-Aw for qemu-devel@nongnu.org; Wed, 28 Jan 2015 10:43:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGUmU-0000Sm-7f for qemu-devel@nongnu.org; Wed, 28 Jan 2015 10:43:54 -0500 Received: from goliath.siemens.de ([192.35.17.28]:42980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGUmT-0000SV-V0 for qemu-devel@nongnu.org; Wed, 28 Jan 2015 10:43:50 -0500 Message-ID: <54C903B3.8070104@siemens.com> Date: Wed, 28 Jan 2015 16:43:47 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <54C8FA00.2060707@siemens.com> <1422459387.22865.105.camel@redhat.com> In-Reply-To: <1422459387.22865.105.camel@redhat.com> Content-Type: text/plain; charset=utf-8 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: Alex Williamson Cc: qemu-devel , kvm 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. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux