From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNzzM-0005Hf-Hl for qemu-devel@nongnu.org; Sun, 31 Aug 2014 03:55:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XNzzG-00045Z-AO for qemu-devel@nongnu.org; Sun, 31 Aug 2014 03:55:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNzzG-00045O-2O for qemu-devel@nongnu.org; Sun, 31 Aug 2014 03:55:46 -0400 Date: Sun, 31 Aug 2014 10:58:57 +0200 From: "Michael S. Tsirkin" Message-ID: <20140831085857.GC1514@redhat.com> References: <1408584508-5946-1-git-send-email-tiejun.chen@intel.com> <1408584508-5946-3-git-send-email-tiejun.chen@intel.com> <20140821161649.GA18265@laptop.dumpdata.com> <53F6978C.9080600@intel.com> <20140824111206.GB9561@redhat.com> <53FAC70F.1080201@intel.com> <53FBF5BD.6060104@intel.com> <53FE7E3A.7050907@intel.com> <53FFD752.2040402@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53FFD752.2040402@intel.com> Subject: Re: [Qemu-devel] [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge specific to IGD passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Chen, Tiejun" Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org, Konrad Rzeszutek Wilk On Fri, Aug 29, 2014 at 09:28:50AM +0800, Chen, Tiejun wrote: > > > On 2014/8/28 8:56, Chen, Tiejun wrote: > >>>>>>>+ */ > >>>>>>>+ dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0), > >>>>>>>+ "xen-igd-passthrough-isa-bridge"); > >>>>>>>+ if (dev) { > >>>>>>>+ r = xen_host_pci_device_get(&hdev, 0, 0, PCI_DEVFN(0x1f, > >>>>>>>0), 0); > >>>>>>>+ if (!r) { > >>>>>>>+ pci_config_set_vendor_id(dev->config, hdev.vendor_id); > >>>>>>>+ pci_config_set_device_id(dev->config, hdev.device_id); > >>>> > >>>>Can you, instead, implement the reverse logic, probing > >>>>the card and supplying the correct device id for PCH? > >>>> > >>> > >>>Here what is your so-called reverse logic as I already asked you > >>>previously? Do you mean I should list all PCHs with a combo illustrated > >>>with the vendor/device id in advance? Then look up if we can find a > >> > >>Michael, > >> > > > >Ping. > > > >Thanks > >Tiejun > > > >>Could you explain this exactly? Then I can try follow-up your idea ASAP > >>if this is necessary and possible. > > Michel, > > Could you give us some explanation for your "reverse logic" when you're > free? > > Thanks > Tiejun So future drivers will look at device ID for the card and figure out how things should work from there. Old drivers still poke at device id of the chipset for this, but maybe qemu can do what newer drivers do: look at the card and figure out what guest should do, then present the appropriate chipset id. This is based on what Jesse said: Practically speaking, we could probably assume specific GPU/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. so the idea is to have a reverse table mapping GPU back to PCH. Present to guest the ID that will let it assume the correct GPU. the problem with these tables is they are hard to keep up to date as new hardware comes out, but as future hardware won't need these hacks, we shall be fine. > >> > >>Thanks > >>Tiejun > >> > >>>matched PCH? If yes, what is that benefit you expect in passthrough > >>>case? Shouldn't we pass these info to VM directly in passthrough case? > >>> > >>>Thanks > >>>Tiejun > >>> > >>> > >>> > >> > >> > >> > > > > > >