Eric W. Biederman wrote:
>> I'm not really happy about using this as a way to distinguish paravirt
>> from non-paravirt in general. At some point we're going to be running
>> paravirt kernels in ring0 within a VT/SVM container - but they'll still
>> be completely paravirtualized kernels.
>>
>
> That wasn't paravirt detection that was do I have permissions to load
> the gdt.
>
Well, a paravirtualized ring0 kernel may still have special constraints
on how the gdt can be set up (page-aligned, read-only, etc).
> Basically we have two choices. Either unconditionally demand
> that %cs %ds %es and %ss are loaded, and so we remove all descriptor
> loading.
>
Yep. At least if the boot-version is new enough to boot this way. The
old native-boot path can reload as much as it likes.
>> I think a better approach is to just do it purely based on the boot
>> params platform field. Ie, something along the lines of:
>>
>> if (boot_params.version < new_enough)
>> goto native_boot;
>> else {
>> for (int i = 0; i < nplatforms; i++)
>> if (boot_params.platform == platforms[i].id)
>> goto *platforms[i].startup
>> panic();
>> }
>>
>
> I think it is much better to test the boot_params.platform field where
> we care. If the platform is a native x86 subarch we don't need
> a magic startup function. If the platform is Xen or lguest
> we can at best copy our boot parameters and jump to their custom
> startup routines.
>
Why not just treat them all in the same way? Especially if we start
sweeping other non-virtual architectures like voyager/visws/etc into the
same mechanism.
My idea was that "goto native_boot" would jump to code which assumes
it's running on real hardware, where there's no problem reloading
gdt/segment registers, etc.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
