Re: [PATCH 1/3] x86: add support for computing the instruction length

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

On Tue, Sep 09, 2014 at 05:25:58PM +0100, Jan Beulich wrote:
> >>> On 09.09.14 at 18:01, <mdontu@bitdefender.com> wrote:
> > I've opted to send a new mail so I can remove Masami from CC, as he's
> > probably not interested in the rest of the conversation.
> > 
> > Right now we have two patches which work around x86/emulator
> > limitations:
> > 
> >  * one computes the instruction length;
> >  * the other uses single stepping to jump over unsupported instructions;
> > 
> > Adding support for the complete x86(_64) instruction set to the
> > existent emulator in Xen would make those two unneeded and while I
> > would like to try my hand at it, I'm not sure the effort would be pay
> > off. Not to mention that I would very much like to _somehow_ catch the
> > 4.5 deadline. I wonder if it's possible to do this in iterations: take
> > this (or a decent derivation of it) in, while Răzvan and I work on doing
> > a better work for 4.6. Am I pushing it? :-)
> 
> Personally I don't think this makes sense to push for 4.5, but in the
> end it'll be Konrad's call. We already have enough other half-way

I think that this particular feature - that is - add extra emulation
(or skipping over certain operations) for new opcodes - should be
deferred to Xen 4.6. The reasons are:

 - It is a complex piece of code and there are so many outstanding 
   patches to review and not enough brains to look at all of them.

 - It will take a couple of iterations to get to a high-quality
   that is required and the time to get all of that done within
   the feature window is mighty hard.

 - Spending the next week working 18hrs to get it in and potentially
   missing the deadline - is really frustrating - and I think it
   would be better if this was implemented with a couple of nice
   non-stressfull months instead of days.

> reviewed patch series that need finalizing, so I don't think this series
> (which was posted just once many weeks ago) is a candidate.
> Furthermore I'm rather unconvinced of this being code useful to
> other than just your product. And finally, we had (with other
> submitters) some bad experience in the past taking what they
> promised they would clean up later.
> 
> Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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