From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOMNH-0008KE-Af for qemu-devel@nongnu.org; Mon, 01 Sep 2014 03:50:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOMNA-0005tF-Ki for qemu-devel@nongnu.org; Mon, 01 Sep 2014 03:50:02 -0400 Received: from mga14.intel.com ([192.55.52.115]:54753) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOMNA-0005sJ-FA for qemu-devel@nongnu.org; Mon, 01 Sep 2014 03:49:56 -0400 Message-ID: <54042514.6090206@intel.com> Date: Mon, 01 Sep 2014 15:49:40 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 References: <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> <20140831085857.GC1514@redhat.com> <5403DEFD.1020704@intel.com> <20140901060506.GA20186@redhat.com> In-Reply-To: <20140901060506.GA20186@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com, qemu-devel@nongnu.org, Konrad Rzeszutek Wilk On 2014/9/1 14:05, Michael S. Tsirkin wrote: > On Mon, Sep 01, 2014 at 10:50:37AM +0800, Chen, Tiejun wrote: >> On 2014/8/31 16:58, Michael S. Tsirkin wrote: >>> 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. >>> >> >> Michael, >> >> Thanks for your explanation. >> >>> 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. >> >> I guess you mean we should create to maintain such a table: >> >> [GPU Card: device_id(s), PCH: device_id] >> >> Then each time, instead of exposing that real PCH device id directly, qemu >> first can get the real GPU device id to lookup this table to present a >> appropriate PCH's device id to the guest. >> >> And looks here that appropriate PCH's device id is not always a that real >> PCH's device id. Right? If I'm wrong please correct me. > > Exactly: we don't really care what the PCH ID is - we only need it > for the guest driver to do the right thing. Agreed. I need to ask Allen to check if one given GPU card device id is always corresponding to one given PCH on both HSW and BDW currently. If yes, I can do this quickly. Otherwise I need some time to establish that sort of connection. Thanks Tiejun > >>> >>> the problem with these tables is they are hard to keep up to date >> >> Yeah. But I think currently we can just start from some modern CPU such as >> HSW and BDW, then things could be easy. >> >> Allen, >> >> Any idea to this suggestion? >> >>> as new hardware comes out, but as future hardware won't need >>> these hacks, we shall be fine. >> >> Yeah. >> >> Thanks >> Tiejun >> >>> >>> >>>>>> >>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> > >