Messages in this thread | | | Date | Thu, 08 Mar 2007 12:18:59 -0800 | From | Jeremy Fitzhardinge <> | Subject | Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree |
| |
Chris Wright wrote: > * Jeremy Fitzhardinge (jeremy@goop.org) wrote: > >> Chris Wright wrote: >> >>> I agree with that, but I think that's esp. for things like create and launch >>> new vcpu. The IPI bit I'm not as clear on, nor running this all on native >>> as well. >>> >>> >> Well, native would fall back to using the existing arch/i386 versions of >> those functions, so that's reasonably straightforward. >> > > It's the fact that we need to leave code in the kernel to run on native, > but also do something dynamically with that same code when running > paravirt that I'm referring to.
Why would it be any different to all the other code we've got behind native pvops?
The ideal simplified case is that we rename smp_send_stop/send_reschedule/prepare_cpus/etc to native_* versions. In the !PARAVIRT case we just call the native_* version directly; in PARAVIRT we call via the native pv_ops structure. Under Xen, all these would implemented independently from the native versions.
> No, it's not the IPI itself, it's the way it's often accessed by the rest of > the kernel (which is intertwined with genapic). I'm happy to avoid apic > altogether since it's effectively worthless for Xen other than > integrating into the existing infrastructure. >
I guess by "rest of the kernel" you mean other stuff in arch/i386. Yes, that's a concern, but maybe we can tease it apart in a sensible way.
J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |