From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: Status IGD pass-through with QEMU/KVM Date: Wed, 28 Jan 2015 08:36:27 -0700 Message-ID: <1422459387.22865.105.camel@redhat.com> References: <54C8FA00.2060707@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: qemu-devel , kvm To: Jan Kiszka Return-path: In-Reply-To: <54C8FA00.2060707@siemens.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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