From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44695) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2wz9-0002z0-As for qemu-devel@nongnu.org; Fri, 04 Jul 2014 02:28:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2wz0-0008Sz-4v for qemu-devel@nongnu.org; Fri, 04 Jul 2014 02:28:39 -0400 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:35571) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2wyz-0008Sk-UF for qemu-devel@nongnu.org; Fri, 04 Jul 2014 02:28:30 -0400 Received: by mail-we0-f170.google.com with SMTP id w61so1184261wes.29 for ; Thu, 03 Jul 2014 23:28:29 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53B64989.3050301@redhat.com> Date: Fri, 04 Jul 2014 08:28:25 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <53B1BAF9.6040800@citrix.com> <20140701053907.GA6108@redhat.com> <20140701170206.GB7640@redhat.com> <53B2F238.7000009@citrix.com> <53B3EDF5.4000802@redhat.com> <20140702140033.GG19068@laptop.dumpdata.com> <53B41C27.4030706@redhat.com> <20140702162337.GB32380@laptop.dumpdata.com> <20140703073212.GA20828@redhat.com> <20140703182611.GH13710@konrad-lan.dumpdata.com> <20140703120928.3a1be7d4@jbarnes-desktop> In-Reply-To: <20140703120928.3a1be7d4@jbarnes-desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jesse Barnes , Konrad Rzeszutek Wilk Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Michael S. Tsirkin" , airlied@linux.ie, daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org, "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , "yang.z.zhang@intel.com" , Stefano Stabellini , Ross Philipson , Anthony Perard , "Chen, Tiejun" Il 03/07/2014 21:09, Jesse Barnes ha scritto: > Practically speaking, we could probably assume specific CPU/PCH combos, > as I don't think they're generally mixed across generations, though SNB > and IVB did have compatible sockets, so there is the possibility of > mixing CPT and PPT PCHs, but those are register identical as far as the > graphics driver is concerned, so even that should be safe. I guess the driver could do that if it finds an unknown PCH device ID. But encoding it in the subsystem device ID could also work and it would be easy to do in the hypervisor. > Beyond that, the other MCH data we need to look at is mirrored into the > GPU's MMIO space on current gens. Heh, that's exactly the same as the paravirtualized solution we were suggesting. ;) Paolo > On older gens, we do need to poke at > the memory controller a bit to get some info (see > intel_setup_mchbar()), but that's not true of newer stuff. Looks like > we only short circuit that on VLV though; we could probably do it on > SNB+.