From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2L5o-0007z1-8l for qemu-devel@nongnu.org; Wed, 02 Jul 2014 10:01:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2L5f-0006Fu-IP for qemu-devel@nongnu.org; Wed, 02 Jul 2014 10:01:00 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:41444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2L5f-0006Fb-2x for qemu-devel@nongnu.org; Wed, 02 Jul 2014 10:00:51 -0400 Date: Wed, 2 Jul 2014 10:00:33 -0400 From: Konrad Rzeszutek Wilk Message-ID: <20140702140033.GG19068@laptop.dumpdata.com> References: <20140630064822.GB14491@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B3EDF5.4000802@redhat.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: Paolo Bonzini Cc: "peter.maydell@linaro.org" , "xen-devel@lists.xensource.com" , "anthony@codemonkey.ws" , "Michael S. Tsirkin" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , "yang.z.zhang@intel.com" , Stefano Stabellini , Ross Philipson , Anthony Perard , "Chen, Tiejun" 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. 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: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support Date: Wed, 2 Jul 2014 10:00:33 -0400 Message-ID: <20140702140033.GG19068@laptop.dumpdata.com> References: <20140630064822.GB14491@redhat.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <53B3EDF5.4000802@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" , "anthony@codemonkey.ws" , "Michael S. Tsirkin" , "Allen M. Kay" , "Kelly.Zytaruk@amd.com" , "qemu-devel@nongnu.org" , "yang.z.zhang@intel.com" , Stefano Stabellini , Ross Philipson , Anthony Perard , "Chen, Tiejun" List-Id: xen-devel@lists.xenproject.org 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. 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?