Re: [Xen-devel] 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

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Konrad Rzeszutek Wilk wrote on 2014-09-26:
> On Thu, Sep 25, 2014 at 04:14:28PM +0100, Jan Beulich wrote:
>>>>> On 25.09.14 at 16:12, <konrad.wilk@xxxxxxxxxx> 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.

This should be another story. We are not expecting to push the IGD passthrough 
patch to Qemu to catch the Xen 4.5. Besides, as you mentioned, they want us to 
redesign the whole them with modification from driver side. It really not an 
easy task and will require more time to do it.

> 
> But oddly enough those patches are in the qemu-traditional!

Yes, but as you known, qemu-traditional is only used by Xen and we don't need 
to consider other usage mode.

> 
> 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,

s/she/he :)

> 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

Qemu-traditional + Xen 4.5 + RMRR patchset will work.

> 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.

I am not sure whether we can catch Oct 13th. Does this means those patch will 
not be accepted by you if we cannot catch Oct 13th?

> 
> 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.


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel