Re: [Xen-devel] [PATCH 11/20] PVH xen: introduce pvh.c

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.05.13 at 02:27, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Thu, 16 May 2013 09:00:44 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 16.05.13 at 03:42, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
>> >>> wrote:
>> > --- a/xen/arch/x86/domain.c
>> > +++ b/xen/arch/x86/domain.c
>> > @@ -1129,6 +1129,10 @@ arch_do_vcpu_op(
>> >          struct domain *d = v->domain;
>> >          struct vcpu_register_vcpu_info info;
>> >  
>> > +        rc = -ENOSYS;
>> > +        if ( is_pvh_vcpu(current) )
>> > +            break;
>> > +
>> 
>> Assuming this is meant to be temporary - yes, this _might_ be
>> acceptable (if accompanied by a proper comment). But then again
>> registering vCPU info is a pretty basic interface (which recently
>> got even moved into common code iirc), so I'm having a hard time
>> seeing why you need to suppress it rather than make it work from
>> the beginning.
> 
> Because I am not as smart as you, and my brain gets full sooner :). I
> only know to do big features in pieces. As it is already, each refresh
> costs me days to merge, resolving conflicts, looking at code to see what
> changed, etc.. then almost always something breaks, and takes a while
> to debug. I got linux side patch to watch out too.

I understand it's hard, the more considering how long you've been
on it already.

> My understanding with previous maintainers was, establish a baseline with
> something working, then keep adding bells and whistles to it. This is an
> effort to that end. I am also OK dropping the ball on pvh and let
> someones else who can finish it all in one shot do it.

And I already indicated various places where I'm fine with such
compromises. But this one - with the code already working for PV
and HVM guests - I simply expect would work without you doing
_anything_ (or if not, it must be something really simple that needs
adjustment).

Jan


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