From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJJhA-00005H-V5 for qemu-devel@nongnu.org; Mon, 18 Aug 2014 05:57:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XJJh5-0001ht-MS for qemu-devel@nongnu.org; Mon, 18 Aug 2014 05:57:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJJh5-0001hW-EB for qemu-devel@nongnu.org; Mon, 18 Aug 2014 05:57:39 -0400 Date: Mon, 18 Aug 2014 11:58:05 +0200 From: "Michael S. Tsirkin" Message-ID: <20140818095805.GB26139@redhat.com> References: <6AF484C0160C61439DE06F17668F3BCB5331D9AD@ORSMSX114.amr.corp.intel.com> <53BED3D4.8040702@redhat.com> <003AAFE53969E14CB1F09B6FD68C3CD478E91417@ORSMSX106.amr.corp.intel.com> <53ED6950.6090101@intel.com> <20140817103245.GD21622@redhat.com> <53F16DB5.8070809@intel.com> <20140818082148.GA26139@redhat.com> <53F1C0E5.3080605@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53F1C0E5.3080605@intel.com> Subject: Re: [Qemu-devel] How to create PCH to support those existing driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Chen, Tiejun" Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , intel-gfx , "Kay, Allen M" , "Wang, Yong Y" , Jesse Barnes , "qemu-devel@nongnu.org" , Don Dutile , Paolo Bonzini On Mon, Aug 18, 2014 at 05:01:25PM +0800, Chen, Tiejun wrote: > On 2014/8/18 16:21, Michael S. Tsirkin wrote: > >On Mon, Aug 18, 2014 at 11:06:29AM +0800, Chen, Tiejun wrote: > >>On 2014/8/17 18:32, Michael S. Tsirkin wrote: > >>>On Fri, Aug 15, 2014 at 09:58:40AM +0800, Chen, Tiejun wrote: > >>>>Michael and Paolo, > >>> > >>>Please re-post discussion on list. These off list ones are just > >>>wasting time since they invariably have to be repeated on list again. > >> > >>Okay, now just reissue this discussion to all related guys. And do you think > >>we need to discuss in public, qemu and xen mail list? > > > >Absolutely. > > Now -CC qemu, xen and intel-gfx. > > If I'm missing someone important please tell me as well. > > > > >>> > >>>>After I created that new machine specific to IGD passthrough, xenigd, now I > >>>>will step next to register the PCH. > >>>> > >>>>IIRC, our complete solution should be as follows: > >>>> > >>>>#1 create a new machine based on piix, xenigd > >>>> > >>>>This is done with Michael help. > >>>> > >>>>#2 register ISA bridge > >>>> > >>>>1> Its still fixed at 1f.0. > >>>>2> ISA bridge's vendor_id/device_id should be emulated but then > >>>> > >>>> subsystem_vendor_id = PCI_VENDOR_ID_XEN; > >>>> subsystem_device_id = ISA Bridge's real device id > >>>> > >>>>This mean we need to change driver to walk with this way. > >>>>For example, in > >>>>case of Linux native driver, > >>>> > >>>>intel_detect_pch() > >>>>{ > >>>> ... > >>>> if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN) > >>>> id = pch->subsystem_device & INTEL_PCH_DEVICE_ID_MASK; > >>>> > >>>>Then driver can get that real device id by 'subsystem_device', right? > >>>> > >>>>This is fine now but how to support those existing drivers which are just > >> > >>Here correct one point, we don't need to care about supporting the legacy > >>driver since the legacy driver still should work qemu-traditional. So we > >>just make sure the existing driver with this subsystem_id way can support > >>those existing and legacy platform. > >> > >>Now this is clear to me. > >> > >>>>dependent on checking real vendor_id/device_id directly, > >>>> > >>>> if (pch->vendor == PCI_VENDOR_ID_INTEL) { > >>>> unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK > >>>> > >>>>Maybe I'm missing something, please hint me. > >>>> > >>>>Thanks > >>>>Tiejun > >>> > >>>The subsystem id was just one idea. > >> > >>But from that email thread, "RH / Intel Virtualization Engineering Meeting - > >>Minutes 7/10", I didn't see other idea we should prefer currently. > >> > >>>What was finally agreed for future drivers is that guests will get all > >>>information they need from the video card, this ID hack was needed only > >>>for very old legacy devices. > >>>http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258 > >>>So this is for newer guests, they will work without need > >>>for hacks, like any other device. > >>> > >> > >>Actually we had a meeting to discuss our future solution, but seems you were > >>on vacation at that moment :) > >> > >>In that meeting we had an agreement between us and some upstream guys. > >> > >>We will have such a PCI capability structure in this PCI device to represent > >>all information in the future. This make sens to Intel as well. > >> > >>Maybe Allen or Paolo known more details. > >> > >>But obviously this a long-term solution, so currently we will work with this > >>subsystem_id way temporarily. And this way is accepted by those guys in the > >>meeting. > > > > > >I don't see the point really. If you are modifying the driver, > > Yes, we need to modify something in the driver. > > >why not modify it to its final form. > > What's your final form? Avoid poking at other devices besides the passed through card. Get everything from BAR and other registers of the card. > As I track that email thread, seems the follows is just a way you guys > achieve a better agreement. > > " > > why not set the subsys vid to the RH/Quamranet/Virtio VID, so it's > > obvious for the use-match? > > That's exactly the suggestion. Though upstream they might be using the > XenSource id since the patches were for Xen. > > Paolo > " > Or I'm missing something? > > Thanks > Tiejun I thought the point of this work is to make existing linux/windows drivers work. Is it or isn't it? Wrt changing drivers, change them to behave sanely, like all other drivers, and avoid poking at the chipset. http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258 Seems to suggest one way to do this. Can what is suggested there work for existing devices? > > > >>> > >>>For existing drivers: Vendor ID is intel anyway. > >> > >>Yes. > >> > >>>For device ID, override it through a property > >>>or something. But I think poking at the real host from > >>>qemu is a mistake though, host is not > >>>protected by iommu. > >>>Two possible suggestions were to reverse-detect > >>>id of the device from the card that is assigned, > >> > >>I guess you're saying pci_get_device(vendor/devices_ids), right? > >> > >>>or just make it a user property, and move the smarts > >>>to management. > >> > >>Sorry could you elaborate this way in detail? > >> > >>Thanks > >>Tiejun > > > > > >Will do but let's do it on the mailing list. > >