From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58137) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X3gXM-0006od-9H for qemu-devel@nongnu.org; Sun, 06 Jul 2014 03:07:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X3gXL-0008IJ-45 for qemu-devel@nongnu.org; Sun, 06 Jul 2014 03:07:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14493) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X3gXK-0008I8-RF for qemu-devel@nongnu.org; Sun, 06 Jul 2014 03:06:59 -0400 Date: Sun, 6 Jul 2014 09:08:40 +0300 From: "Michael S. Tsirkin" Message-ID: <20140706060840.GD5007@redhat.com> References: <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> <53B64989.3050301@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B64989.3050301@redhat.com> 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: Paolo Bonzini Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , Konrad Rzeszutek Wilk , airlied@linux.ie, daniel.vetter@ffwll.ch, intel-gfx@lists.freedesktop.org, "Kelly.Zytaruk@amd.com" , Jesse Barnes , "qemu-devel@nongnu.org" , "yang.z.zhang@intel.com" , Stefano Stabellini , Ross Philipson , Anthony Perard , "Chen, Tiejun" On Fri, Jul 04, 2014 at 08:28:25AM +0200, Paolo Bonzini wrote: > 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. I would say if possible, do this unconditionally. If this logic is strictly required then I would also check the subsystem vendor id and skip the PCH tricks if it matches Xen. > But > encoding it in the subsystem device ID could also work and it would be easy > to do in the hypervisor. Right, but that's custom code in the hypervisor as opposed to the generic one. If generic one can work, that's much better. > >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+.