From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Discussion on whether to continue with the patches for Xen 4.5 Re: [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT Date: Fri, 26 Sep 2014 09:55:29 -0400 Message-ID: <20140926135529.GG30097@laptop.dumpdata.com> References: <541FFFC50200007800036C28@mail.emea.novell.com> <541FE65A.8070803@intel.com> <542017E80200007800036D1E@mail.emea.novell.com> <5420D357.1060202@intel.com> <5422A08C020000780003814F@mail.emea.novell.com> <5423E98E0200007800038C27@mail.emea.novell.com> <20140925141215.GC20089@laptop.dumpdata.com> <54244D7402000078000390F2@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <54244D7402000078000390F2@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , paul.durrant@citrix.com Cc: Yang Z Zhang , Tiejun Chen , Kevin Tian , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Thu, Sep 25, 2014 at 04:14:28PM +0100, Jan Beulich wrote: > >>> On 25.09.14 at 16:12, wrote: > > On Thu, Sep 25, 2014 at 09:08:14AM +0100, Jan Beulich wrote: > >> Considering it's a bug that gets fixed, I would think so. But as for > >> anything more involved, Konrad as the release manager will have > >> the final say. Hey Paul, I CC-ed you on this as I have a question below. > > > > What are the non-bugs (features) that we speak of? > > There are no non-bug changes here. It's just that the issue has > always been there, so is also not a regression. OK, patches do not introduce regressions - but they fix bugs with PCIe passthrough devices (especially when passing in USB and GPUs?). > > > Are the the ones that had > > been posted (and then one written by Jan and then reworked)? > > Yes, and which need further reworking. > > > Please do be aware that the feature freeze window time has just elapsed > > (yesterday) > > so anything to be considered a feature should have been posted before or on > > that date. > > > > Please keep in mind that bug-fixes can be posted and checked in _after_ the > > feature freeze. But as the RCs numbers increases the likehood of bugs being > > checked in goes down (to reduce the risk of further regressions instroduced > > by bug-fixes). > > That's the main reason why I pointed at you as the release manager > - together with this not being a new bug our willingness to add a fix > for this will presumably decrease as time goes on. The initial justification (this is my understanding - please correct me if I am incorrect) for these patches is that it will expand the use-case of PCI passthrough for the use case of graphics cards. Which is fantastic because we really need to make sure that all works. When I saw "xen: add Intel IGD passthrough support" patches I jumped on them to help them along to get in QEMU. They now seem to have hit a roadblock were they are wating on Chen to redesign them - such that they are only using the registers from the GPU card - and not the bridge one. That of course depends on the GPU drivers (Windows in particular, Linux ones I posted an RFC ones that could be used) being updated to do that. .. And I have not seen any update on that. Of course even if they do go out (the Windows drivers), and then the QEMU work can progress - it won't be in QEMU 2.0 (which is in Xen 4.5), but rather in QEMU 2.x. I haven't seen any emails from Chen Tiejun to Stefano about backporting those in qemu-xen in our tree. But oddly enough those patches are in the qemu-traditional! My understanding is that the multiple ioreq-server patches are also an requirement for this. But I don't know if they work with qemu-traditional (I think they should work fine with that, but not sure - CC-ing Paul to find out). Then there is the complication of that folks in China are celebrating from Oct 1st -> Oct 7th - so that means Chien (I presume she works there, but I could be very well mistaken - please correct me) would have to answer/fix all the patches in the next two working days. With the first RC going out on October 15th, that means a total of four working days to get all of this done, reviewed, fixed, and tested. And working under stress to get this done can mean introducing subtle bugs (this is based on my personal experience, so your experience might be different). Anyhow, I really need to know if - are all of the code pieces (minus the patches we are discussing) for this full GPU functionality in the Xen codebase and will it work with Xen 4.5 or will it require extra additional patches? And also, can all of those patches be tested/reviewed/posted by Oct 13th? As in, is this patchset the last piece of the puzzle? And by tested I mean with the passthrough and without, and with various size guests doing migrations (without devices) multiple times (say ten) - and 32 or 64 bit. The QA matrix means at least 8 variations (32/64 - with PCIe passthrough, and without, 2GB or 8GB or 12GB) by my reckoning. Sorry for being so aggressive about the testing part but I am very adverse to regressions - as they have bit me in the past and left me with an strong aversion to them.