From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJYOX-00065T-Aw for qemu-devel@nongnu.org; Mon, 18 Aug 2014 21:39:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XJYOS-0000os-70 for qemu-devel@nongnu.org; Mon, 18 Aug 2014 21:39:29 -0400 Received: from mga01.intel.com ([192.55.52.88]:14183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJYOR-0000oj-Sl for qemu-devel@nongnu.org; Mon, 18 Aug 2014 21:39:24 -0400 Message-ID: <53F2AAC6.7000501@intel.com> Date: Tue, 19 Aug 2014 09:39:18 +0800 From: "Chen, Tiejun" MIME-Version: 1.0 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> <20140818095805.GB26139@redhat.com> In-Reply-To: <20140818095805.GB26139@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" 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 2014/8/18 17:58, Michael S. Tsirkin wrote: > 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. Allen, Could you reply this? > >> 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? Yes. We need change driver as I said previously like this, >>>>>> 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; This is a minimal change to driver as we discussed. > > 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? > Again, Allen, Are you sure if this suggestion can work? Thanks Tiejun > >>> >>>>> >>>>> 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. >>> > >