Paravirt-ops VMI / Xen / lrustyvisor merge status
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
Quoted 10 lines · 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?
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).
Quoted 5 lines
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.
Quoted 9 lines · Rusty Russell
Quoted 4 lines
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.
Quoted 11 lines
Quoted 7 lines
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
Quoted 3 lines · Zachary Amsden
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?
Quoted 3 lines
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
Quoted 9 lines · Jeremy Fitzhardinge
Quoted 4 lines · Zachary Amsden
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
Quoted 3 lines · Zachary Amsden
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.
Quoted 10 lines · Rusty Russell
Quoted 4 lines · Zachary Amsden
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
Quoted 7 lines · Rusty Russell
Quoted 4 lines · Zachary Amsden
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.
Quoted 6 lines
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
Quoted 3 lines · Zachary Amsden
I believe there was a patch that got applied that turned it off by default if
CONFIG_PARAVIRTwas 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
Quoted 3 lines · Zachary Amsden
I believe there was a patch that got applied that turned it off by default if
CONFIG_PARAVIRTwas 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.
Quoted 4 lines
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
Quoted 6 lines · Andi Kleen
Quoted 3 lines
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)
Quoted 2 lines
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.
Quoted 2 lines · Zachary Amsden
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?).
Quoted 2 lines
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
Quoted 4 lines · 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?
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
Quoted 8 lines · Andi Kleen
Quoted 5 lines · 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?
Quoted 4 lines
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