From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2LBd-0007X0-Jw for qemu-devel@nongnu.org; Wed, 02 Jul 2014 10:07:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2LBX-00009E-Fj for qemu-devel@nongnu.org; Wed, 02 Jul 2014 10:07:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2LBX-00008Q-7U for qemu-devel@nongnu.org; Wed, 02 Jul 2014 10:06:55 -0400 Date: Wed, 2 Jul 2014 17:08:43 +0300 From: "Michael S. Tsirkin" Message-ID: <20140702140843.GB6077@redhat.com> References: <53B110CA.6070606@intel.com> <20140630090511.GB15777@redhat.com> <53B1BAF9.6040800@citrix.com> <20140701053907.GA6108@redhat.com> <20140701170206.GB7640@redhat.com> <53B2F238.7000009@citrix.com> <53B3EDF5.4000802@redhat.com> <20140702140033.GG19068@laptop.dumpdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140702140033.GG19068@laptop.dumpdata.com> Subject: Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konrad Rzeszutek Wilk Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , "yang.z.zhang@intel.com" , Stefano Stabellini , Ross Philipson , "Chen, Tiejun" , Anthony Perard , Paolo Bonzini On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote: > > Il 01/07/2014 19:39, Ross Philipson ha scritto: > > > > > >We do IGD pass-through in our project (XenClient). The patches > > >originally came from our project. We surface the same ISA bridge and > > >have never had activation issues on any version of Widows from XP to > > >Win8. We do not normally run server platforms so I can't say for sure > > >there. > > > > The problem is not activation, the problem is that the patches are making > > assumptions on the driver and the firmware that might work today but are > > IMHO just not sane. > > > > I would have no problem with a clean patchset that adds a new machine type > > and doesn't touch code in "-M pc", but it looks like mst disagrees. > > Ultimately, if a patchset is too hacky for upstream, you can include it in > > your downstream XenClient (and XenServer) QEMU branch. It happens. > > And then this discussion will come back again in a year when folks > rebase and ask: Why hasn't this been done upstream. > > Then the discussion resumes .. > > With this long thread I lost a bit context about the challenges > that exists. But let me try summarizing it here - which will hopefully > get some consensus. Before I answer could you clarify please: by Southbridge do you mean the PCH at slot 1f or the MCH at slot 0 or both? > 1). Fix IGD hardware to not use Southbridge magic addresses. > We can moan and moan but I doubt it is going to change. > > 2). Since we need the Southbridge magic addresses, we can expose > an bridge. [I think everybody agrees that we need to do > that since 1) is no go). > > 3). What kind of bridge. We can do: > > a) Two bridges - one 'passthrough' and the legacy ISA bridge > that QEMU emulates. Both Linux and Windows are OK with > two bridges (even thought it is pretty weird). > > b) One bridge - the one that QEMU emulates - and lets emulate > more of the registers (by emulate - I mean for some get the > data from the real hardware). > > b1). We can't use the legacy because the registers are > above 256 (is that correct? Did I miss something?) > > b2) We would need to use the Q35. > b2a). If we need Q35, that needs to be exposed in > for Xen guests. That means exposing the > MMCONFIG and restructing the E820 to fit that > in. > Problem: > - Migration is not working with Q35. > (But for v1 you wouldn't migrate, however > later hardware will surely have SR-IOV so > we will need to migrate). > > - There are no developers who have an OK > from their management to focus on this. > (Potential solution: Poke Intel management to see > if they can get more developers on it) > > > 4). Code does a bit of sysfs that could use some refacturing with > the KVM code. > Problem: More time needed to do the code restructing. > > > Is that about correct? > > What are folks timezones and the best days next week to talk about > this on either Google Hangout or the phone? From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support Date: Wed, 2 Jul 2014 17:08:43 +0300 Message-ID: <20140702140843.GB6077@redhat.com> References: <53B110CA.6070606@intel.com> <20140630090511.GB15777@redhat.com> <53B1BAF9.6040800@citrix.com> <20140701053907.GA6108@redhat.com> <20140701170206.GB7640@redhat.com> <53B2F238.7000009@citrix.com> <53B3EDF5.4000802@redhat.com> <20140702140033.GG19068@laptop.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20140702140033.GG19068@laptop.dumpdata.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: Konrad Rzeszutek Wilk Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , "yang.z.zhang@intel.com" , Stefano Stabellini , Ross Philipson , "Chen, Tiejun" , Anthony Perard , Paolo Bonzini List-Id: xen-devel@lists.xenproject.org On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote: > > Il 01/07/2014 19:39, Ross Philipson ha scritto: > > > > > >We do IGD pass-through in our project (XenClient). The patches > > >originally came from our project. We surface the same ISA bridge and > > >have never had activation issues on any version of Widows from XP to > > >Win8. We do not normally run server platforms so I can't say for sure > > >there. > > > > The problem is not activation, the problem is that the patches are making > > assumptions on the driver and the firmware that might work today but are > > IMHO just not sane. > > > > I would have no problem with a clean patchset that adds a new machine type > > and doesn't touch code in "-M pc", but it looks like mst disagrees. > > Ultimately, if a patchset is too hacky for upstream, you can include it in > > your downstream XenClient (and XenServer) QEMU branch. It happens. > > And then this discussion will come back again in a year when folks > rebase and ask: Why hasn't this been done upstream. > > Then the discussion resumes .. > > With this long thread I lost a bit context about the challenges > that exists. But let me try summarizing it here - which will hopefully > get some consensus. Before I answer could you clarify please: by Southbridge do you mean the PCH at slot 1f or the MCH at slot 0 or both? > 1). Fix IGD hardware to not use Southbridge magic addresses. > We can moan and moan but I doubt it is going to change. > > 2). Since we need the Southbridge magic addresses, we can expose > an bridge. [I think everybody agrees that we need to do > that since 1) is no go). > > 3). What kind of bridge. We can do: > > a) Two bridges - one 'passthrough' and the legacy ISA bridge > that QEMU emulates. Both Linux and Windows are OK with > two bridges (even thought it is pretty weird). > > b) One bridge - the one that QEMU emulates - and lets emulate > more of the registers (by emulate - I mean for some get the > data from the real hardware). > > b1). We can't use the legacy because the registers are > above 256 (is that correct? Did I miss something?) > > b2) We would need to use the Q35. > b2a). If we need Q35, that needs to be exposed in > for Xen guests. That means exposing the > MMCONFIG and restructing the E820 to fit that > in. > Problem: > - Migration is not working with Q35. > (But for v1 you wouldn't migrate, however > later hardware will surely have SR-IOV so > we will need to migrate). > > - There are no developers who have an OK > from their management to focus on this. > (Potential solution: Poke Intel management to see > if they can get more developers on it) > > > 4). Code does a bit of sysfs that could use some refacturing with > the KVM code. > Problem: More time needed to do the code restructing. > > > Is that about correct? > > What are folks timezones and the best days next week to talk about > this on either Google Hangout or the phone?