From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJIor-0004eD-HL for qemu-devel@nongnu.org; Mon, 18 Aug 2014 05:01:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XJIom-0002Eu-BJ for qemu-devel@nongnu.org; Mon, 18 Aug 2014 05:01:37 -0400 Received: from mga11.intel.com ([192.55.52.93]:54177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XJIom-0002Ea-4G for qemu-devel@nongnu.org; Mon, 18 Aug 2014 05:01:32 -0400 Message-ID: <53F1C0E5.3080605@intel.com> Date: Mon, 18 Aug 2014 17:01:25 +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> In-Reply-To: <20140818082148.GA26139@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 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? 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 > >>> >>> 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. >