From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzo9C-0002fw-3O for qemu-devel@nongnu.org; Wed, 25 Jun 2014 10:26:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wzo94-00076C-E9 for qemu-devel@nongnu.org; Wed, 25 Jun 2014 10:26:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzo94-000765-4z for qemu-devel@nongnu.org; Wed, 25 Jun 2014 10:25:54 -0400 Date: Wed, 25 Jun 2014 17:26:05 +0300 From: "Michael S. Tsirkin" Message-ID: <20140625142605.GB15277@redhat.com> References: <53AA9B58.6050803@intel.com> <20140625095533.GE6357@redhat.com> <53AA9D79.3080003@redhat.com> <53AA9F3A.5030004@intel.com> <20140625102119.GJ6357@redhat.com> <53AABC81.2090206@redhat.com> <20140625134727.GB14578@redhat.com> <53AAD45A.5090905@redhat.com> <20140625141027.GE14578@redhat.com> <53AAD9AC.2010803@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53AAD9AC.2010803@redhat.com> Subject: Re: [Qemu-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com, allen.m.kay@intel.com, Kelly.Zytaruk@amd.com, qemu-devel@nongnu.org, anthony.perard@citrix.com, anthony@codemonkey.ws, yang.z.zhang@intel.com, "Chen, Tiejun" On Wed, Jun 25, 2014 at 04:16:12PM +0200, Paolo Bonzini wrote: > Il 25/06/2014 16:10, Michael S. Tsirkin ha scritto: > >On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote: > >>Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto: > >>>OK, so how about doing this: either for the ISA > >>>bridge, or for the VGA card itself: > >>> > >>> set subsystem vendor id to PCI_VENDOR_ID_XEN, > >>> set subsystem device id to PCH device id > >> > >>That would work, but the same problem would then arise for the MCH. The > >>driver there is banging at random places in the configuration space. > >> > >>This is why I asked for a solution that is future-proof, and since you can > >>make one that works for both MCH and PCH it is nice to do the work just > >>once. > > > >Q35 has MCH, so I don't see why we can't make that work, > >extending it as appropriate. > > Is Q35's MCH configuration space entirely compatible with newer chipsets > that are in the host and that the IGD driver expects? I dont think it's > safe to assume that. So far only a couple of registers were emulated. I don't see any conflicts there. Implementing a newer MCH would also be useful, outside xen. > >Doing that for PIIX is iffy. > >Should we really do that? Q35 is there. > > Xen doesn't support Q35, You have to start somewhere :) > and Q35 is still lacking migration. It isn't, just disable ahci. > So it's really a chicken-and-egg problem. > > Paolo Well I don't see how is this PV thing any better. Again, experience shows if we don't push hard enough for people to fix their stuff, and just merge crappy work-arounds "as a 1st step", motivation for people to fix their stuff disappears, and the second step is never taken. Let's see the clean if incomplete solution as the first step. We can add work-arounds for legacy configs as the second step. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [v5][PATCH 0/5] xen: add Intel IGD passthrough support Date: Wed, 25 Jun 2014 17:26:05 +0300 Message-ID: <20140625142605.GB15277@redhat.com> References: <53AA9B58.6050803@intel.com> <20140625095533.GE6357@redhat.com> <53AA9D79.3080003@redhat.com> <53AA9F3A.5030004@intel.com> <20140625102119.GJ6357@redhat.com> <53AABC81.2090206@redhat.com> <20140625134727.GB14578@redhat.com> <53AAD45A.5090905@redhat.com> <20140625141027.GE14578@redhat.com> <53AAD9AC.2010803@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <53AAD9AC.2010803@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Paolo Bonzini Cc: peter.maydell@linaro.org, xen-devel@lists.xensource.com, stefano.stabellini@eu.citrix.com, allen.m.kay@intel.com, Kelly.Zytaruk@amd.com, qemu-devel@nongnu.org, anthony.perard@citrix.com, anthony@codemonkey.ws, yang.z.zhang@intel.com, "Chen, Tiejun" List-Id: xen-devel@lists.xenproject.org On Wed, Jun 25, 2014 at 04:16:12PM +0200, Paolo Bonzini wrote: > Il 25/06/2014 16:10, Michael S. Tsirkin ha scritto: > >On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote: > >>Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto: > >>>OK, so how about doing this: either for the ISA > >>>bridge, or for the VGA card itself: > >>> > >>> set subsystem vendor id to PCI_VENDOR_ID_XEN, > >>> set subsystem device id to PCH device id > >> > >>That would work, but the same problem would then arise for the MCH. The > >>driver there is banging at random places in the configuration space. > >> > >>This is why I asked for a solution that is future-proof, and since you can > >>make one that works for both MCH and PCH it is nice to do the work just > >>once. > > > >Q35 has MCH, so I don't see why we can't make that work, > >extending it as appropriate. > > Is Q35's MCH configuration space entirely compatible with newer chipsets > that are in the host and that the IGD driver expects? I dont think it's > safe to assume that. So far only a couple of registers were emulated. I don't see any conflicts there. Implementing a newer MCH would also be useful, outside xen. > >Doing that for PIIX is iffy. > >Should we really do that? Q35 is there. > > Xen doesn't support Q35, You have to start somewhere :) > and Q35 is still lacking migration. It isn't, just disable ahci. > So it's really a chicken-and-egg problem. > > Paolo Well I don't see how is this PV thing any better. Again, experience shows if we don't push hard enough for people to fix their stuff, and just merge crappy work-arounds "as a 1st step", motivation for people to fix their stuff disappears, and the second step is never taken. Let's see the clean if incomplete solution as the first step. We can add work-arounds for legacy configs as the second step. -- MST