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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Sep 25, 2014 at 04:14:28PM +0100, Jan Beulich wrote:
> >>> On 25.09.14 at 16:12, <konrad.wilk@oracle.com> 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.