From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wrnm9-0006vQ-Oh for qemu-devel@nongnu.org; Tue, 03 Jun 2014 08:25:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wrnm2-0001bv-9p for qemu-devel@nongnu.org; Tue, 03 Jun 2014 08:25:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12629) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wrnm2-0001bF-2J for qemu-devel@nongnu.org; Tue, 03 Jun 2014 08:25:02 -0400 Message-ID: <538DBE88.2090607@redhat.com> Date: Tue, 03 Jun 2014 14:24:40 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1401440369-29929-1-git-send-email-tiejun.chen@intel.com> <1401440369-29929-3-git-send-email-tiejun.chen@intel.com> <538D8B59.4070105@redhat.com> <538DB4B4.6000602@eu.citrix.com> <13644003.20140603142115@eikelenboom.it> In-Reply-To: <13644003.20140603142115@eikelenboom.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [v4][PATCH 2/5] xen, gfx passthrough: create intel isa bridge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sander Eikelenboom , George Dunlap Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com, Ian Campbell , mst@redhat.com, allen.m.kay@intel.com, Stefano Stabellini , Ian Jackson , Kelly.Zytaruk@amd.com, qemu-devel@nongnu.org, anthony.perard@citrix.com, Tim Deegan , Anthony Liguori , yang.z.zhang@intel.com, Tiejun Chen , George Dunlap , Konrad Rzeszutek Wilk Il 03/06/2014 14:21, Sander Eikelenboom ha scritto: > > The last part should perhaps be fixed in the driver/firmware (for instance > the assumption the device is always device 00:02.0, that's valid for real intel > hardware, but not necessary for passthrough or emulation). A requirement for > using the latest firmware/drivers for passthrough to work could be acceptable i > guess ? The problem is worse than that. The assumptions are that the driver can make choices based on the device/vendor IDs of 00:1f.0, and that the driver can read/write to the config space of 00:00.0. Paolo