Rusty Russell wrote: > On Mon, 2006-07-31 at 01:50 -0700, Zachary Amsden wrote: > >> Rusty Russell wrote: >> >>>> fixmap-bootparam.patch >>>> >>> While this would justify the above patch, it is IMHO, the wrong approach >>> for adding a paravirt module later: a module shouldn't fail to load >>> because you forgot a boot cmdline param. I really think a #ifdef >>> CONFIG_XXX_MODULE would be clearer. >>> >> We can't rely on a compile time kernel option - we really must have a >> boot parameter. This is not the wrong approach. If you forgot to add >> the boot parameter, so be it. You reboot and the paravirt module can >> load. The whole approach only makes sense if you can fully virtualize >> the kernel boot, so this is a completely plausible scenario. >> > > The approach also makes sense for booting a kernel on native hardware, > then inserting a hypervisor later (ie. turning it into dom0). I'll not > be relying on an obscure cmdline boot option for that... > But surely, you would provide room for it? I don't care how obscure it is, I just care that it is possible. >> What we don't want to do is force Linux to have to move the fixmap at >> runtime. I think that could be very, very messy. Course, it may be >> possible (with a dynamic fixmap, it moves into that realm). But to >> completely remove the boot parameter without the ability to change the >> fixmap at runtime makes dynamic loading of a hypervisor module impossible. >> > > No, because if they compiled the kernel with (say) CONFIG_VMI=m, the > fixmap would always be low even for "native". No cmdline option > necessary... > Sure, this is much cleaner - with a nicely configured kernel. >> Besides, it is useful for testing the performance impact of reducing >> lowmem - which I don't think has been adequately benchmarked to this >> day, and is still an area of investigation. >> > > Sure, but that hardly has to go into the mainline... > > This is a change only useful for paravirtualization, yet it's not #ifdef > CONFIG_PARAVIRT'ed. I feel it's a little dishonest (and mission > creepish) to push this as some kind of general change, when a three-line > patch will do what we need for now... > I have no problem waiting to push this change, but I think we absolutely must have it. The point is, without this patch, it is possible to compile a kernel in such a way that the kernel will never be able to relocate the fixmap to provide room for a post-boot-time hypervisor. In which case, the kernel is limited to the set of compiled in boot-time hypervisors, which may not be sufficient. If someone decides to drop vendor X's hypervisor support from the compiled in set in distro Y, vendor X has no way to run distro Y paravirtualized. If a new vendor emerges on the scene in 2 years time, and supporting VMs that run Linux kernel 2.6.19 with high performance is of critical importance, that vendor is locked out of the market. Having configuration time chosen hypervisors leaves room to start this type of compatibility war, and with multiple emerging hypervisor vendors, I think that is something we really do not want to see. We want end users to be able to use the full functionality and performance that paravirtualization can provide, regardless of which hypervisor or distro they are using. Paravirtualization should be a _feature_ the kernel provides, not a mechanism to limit compatibility to a particular set of software. That is the subtle point I am pushing for with this change. Zach
