Paravirt-ops VMI / Xen / lrustyvisor merge status

Paravirt-ops VMI / Xen / lrustyvisor merge status

[Zachary Amsden]

So, as 2.6.21-rc1 is approaching, what is the upstream merge status for 
the paravirt-ops backends?  I believe VMI is in Andi's tree, plus or 
minus some bugfixes that are still being whittled in, but Andi, do you 
think the VMI code is in good shape for merging?

It would be nice for everyone to clarify their upstream plans - is the 
goal still to get Xen and lguest merged for the next kernel release?

Rusty, you mentioned you had a patchset to push, when do you expect to 
have it ready?

Chris / Jeremy - perhaps I missed it, but I haven't seen updated Xen 
paravirt-ops patches go out yet - is 2.6.21 still the merge target?

I don't want to be pushy, but I do want our code to get merged, and 
time's a ticking.  I think we're all in good shape, but the sooner the 
code all gets merged the sooner we can tackle the remaining cleanup / 
polishing tasks.  One of which is separating the paravirt-ops into GPL 
and non-GPL exports, which we need consensus on where the line is, but 
can't really achieve it until everyone is happy with the finalized set 
of paravirt-ops.  Any patch that tries to do this now would just cause 
rejects later and slow all of our merges.

Zach

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Rusty Russell]

On Thu, 2007-02-08 at 21:28 -0800, Zachary Amsden wrote:
> So, as 2.6.21-rc1 is approaching, what is the upstream merge status for 
> the paravirt-ops backends?  I believe VMI is in Andi's tree, plus or 
> minus some bugfixes that are still being whittled in, but Andi, do you 
> think the VMI code is in good shape for merging?
> 
> It would be nice for everyone to clarify their upstream plans - is the 
> goal still to get Xen and lguest merged for the next kernel release?
> 
> Rusty, you mentioned you had a patchset to push, when do you expect to 
> have it ready?

I'm just doing the final file moving now (everything in
arch/i386/lguest), expect to send out something within 48 hours (I need
to sync up to latest git tree, too).

> One of which is separating the paravirt-ops into GPL 
> and non-GPL exports, which we need consensus on where the line is, but 
> can't really achieve it until everyone is happy with the finalized set 
> of paravirt-ops.  Any patch that tries to do this now would just cause 
> rejects later and slow all of our merges.

Yes, I have a patch, but it breaks kvm.  I'm waiting until things settle
before fixing it.

Cheers,
Rusty.

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Zachary Amsden]

Rusty Russell wrote:
>
>> Rusty, you mentioned you had a patchset to push, when do you expect to 
>> have it ready?
>>     
>
> I'm just doing the final file moving now (everything in
> arch/i386/lguest), expect to send out something within 48 hours (I need
> to sync up to latest git tree, too).
>   

Cool.

>   
>> One of which is separating the paravirt-ops into GPL 
>> and non-GPL exports, which we need consensus on where the line is, but 
>> can't really achieve it until everyone is happy with the finalized set 
>> of paravirt-ops.  Any patch that tries to do this now would just cause 
>> rejects later and slow all of our merges.
>>     
>
> Yes, I have a patch, but it breaks kvm.  I'm waiting until things settle
> before fixing it.
>   

I think the only other open issue we had was how to cleanly do the 
sysenter disable for Xen.  We want it on for sure, and so does native, 
but Xen needs to disable it.  This could be tied into some nosegneg 
stuff, I can't remember exactly if they were separate patches or what 
happened to the nosegneg stuff.  Presumedly, Xen still needs that as well?

Zach

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Jeremy Fitzhardinge]

Zachary Amsden wrote:
> I think the only other open issue we had was how to cleanly do the
> sysenter disable for Xen.  We want it on for sure, and so does native,
> but Xen needs to disable it.

You want sysenter as the preferred way of getting into the kernel?

>   This could be tied into some nosegneg stuff, I can't remember
> exactly if they were separate patches or what happened to the nosegneg
> stuff.  Presumedly, Xen still needs that as well?

Yep.  At the moment it's a note compiled into the vsyscall .so
controlled by CONFIG_XEN.

    J

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Zachary Amsden]

Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>   
>> I think the only other open issue we had was how to cleanly do the
>> sysenter disable for Xen.  We want it on for sure, and so does native,
>> but Xen needs to disable it.
>>     
>
> You want sysenter as the preferred way of getting into the kernel?
>   

Yup.

Zach

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Rusty Russell]

On Thu, 2007-02-08 at 22:12 -0800, Zachary Amsden wrote:
> I think the only other open issue we had was how to cleanly do the 
> sysenter disable for Xen.  We want it on for sure, and so does native, 
> but Xen needs to disable it.

I disable it too: you simply make sure cpuid says it doesn't have SEP
and it's all good...

A little confused,
Rusty.

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Jeremy Fitzhardinge]

Rusty Russell wrote:
> On Thu, 2007-02-08 at 22:12 -0800, Zachary Amsden wrote:
>   
>> I think the only other open issue we had was how to cleanly do the 
>> sysenter disable for Xen.  We want it on for sure, and so does native, 
>> but Xen needs to disable it.
>>     
>
> I disable it too: you simply make sure cpuid says it doesn't have SEP
> and it's all good...
>   
Works for me.

    J

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Zachary Amsden]

Rusty Russell wrote:
> On Thu, 2007-02-08 at 22:12 -0800, Zachary Amsden wrote:
>   
>> I think the only other open issue we had was how to cleanly do the 
>> sysenter disable for Xen.  We want it on for sure, and so does native, 
>> but Xen needs to disable it.
>>     
>
> I disable it too: you simply make sure cpuid says it doesn't have SEP
> and it's all good...
>
> A little confused,
> Rusty.
>   

I believe there was a patch that got applied that turned it off by 
default if CONFIG_PARAVIRT was enabled.  Doing it the cpuid way is the 
right solution, IMHO.

Zach

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Jeremy Fitzhardinge]

Zachary Amsden wrote:
> I believe there was a patch that got applied that turned it off by
> default if CONFIG_PARAVIRT was enabled.  Doing it the cpuid way is the
> right solution, IMHO.

That was true for other things, but I don't think we ever did that for
sysenter (there's no config option to turn off sysenter).  Its not true
now, anyway.

    J

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Rusty Russell]

On Thu, 2007-02-08 at 22:59 -0800, Zachary Amsden wrote:
> I believe there was a patch that got applied that turned it off by 
> default if CONFIG_PARAVIRT was enabled.  Doing it the cpuid way is the 
> right solution, IMHO.

Ah, yes, the VDSO issue.  This is separate, and does need fixing. 

Basically, if the user doesn't select COMPAT_VDSO, we don't have a
problem.  Currently they don't get offered COMPAT_VDSO if PARAVIRT is
enabled, but we *still* disable vdso in that case (unless vdso=1 is on
cmdline).

I think the best choice is to rework COMPAT_VDSO to a general "support
old glibcs" option, which will either (1) map it fixed if !
CONFIG_PARAVIRT, or (2) disable it if CONFIG_PARAVIRT.

I'll send that soon...

Cheers,
Rusty.

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Andi Kleen]

> I'm just doing the final file moving now (everything in
> arch/i386/lguest), expect to send out something within 48 hours (I need
> to sync up to latest git tree, too).

Hmm, how much baking did it get yet outside rustylabs? Has it been much 
externally tested at all? 

Also I don't think there hasn't been any review yet. Perhaps it's a little
late now.

-Andi

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Rusty Russell]

On Fri, 2007-02-09 at 08:35 +0100, Andi Kleen wrote:
> > I'm just doing the final file moving now (everything in
> > arch/i386/lguest), expect to send out something within 48 hours (I need
> > to sync up to latest git tree, too).
> 
> Hmm, how much baking did it get yet outside rustylabs? Has it been much 
> externally tested at all? 

Judging from the bug reports, I have some users 8)

> Also I don't think there hasn't been any review yet. Perhaps it's a little
> late now.

We'll see.  It's pretty self-contained, though.

Rusty.

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Jeremy Fitzhardinge]

Zachary Amsden wrote:
> Chris / Jeremy - perhaps I missed it, but I haven't seen updated Xen
> paravirt-ops patches go out yet - is 2.6.21 still the merge target?

Yes.  I spent today updating to address the review comments, and I think
Chris is in the process of rebasing to .20 for a repost soon (tomorrow?).

> I don't want to be pushy, but I do want our code to get merged, and
> time's a ticking.

Me too.  I'm eager to be getting on to something else (which probably
means SMP at this point).

    J

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Andi Kleen]

On Friday 09 February 2007 06:28, Zachary Amsden wrote:
> So, as 2.6.21-rc1 is approaching, what is the upstream merge status for 
> the paravirt-ops backends?  I believe VMI is in Andi's tree, plus or 
> minus some bugfixes that are still being whittled in, but Andi, do you 
> think the VMI code is in good shape for merging?

I don't know in what shape it is in as it hasn't been tested by me.
From the looks it looks reasonable enough for merging. But I didn't like
some of your recent updates.

-Andi

Re: Paravirt-ops VMI / Xen / lrustyvisor merge status

[Zachary Amsden]

Andi Kleen wrote:
> On Friday 09 February 2007 06:28, Zachary Amsden wrote:
>   
>> So, as 2.6.21-rc1 is approaching, what is the upstream merge status for 
>> the paravirt-ops backends?  I believe VMI is in Andi's tree, plus or 
>> minus some bugfixes that are still being whittled in, but Andi, do you 
>> think the VMI code is in good shape for merging?
>>     
>
> I don't know in what shape it is in as it hasn't been tested by me.
> From the looks it looks reasonable enough for merging. But I didn't like
> some of your recent updates.
>   

If you think any of them can be done cleaner, let me know and I will 
redo the patches.

The USE_REAL_TIME_DELAY stuff is really ugly, and mostly a hack.  You 
can drop it.  Our fix should be to not let the virtual hardware drive 
the physical hardware that fast, or to recognize the panic state in 
delay loops and start respecting instead of ignoring delay.

Zach