Zachary Amsden wrote:
>>
>> Actually, that's a non-starter. It won't work if the kernel is
>> running in ring 0.
>
> And if you are running in ring 0, why is there an issue with delaying
> the paravirtual startup code? Either you are in HVM, in which case
> you can transfer paravirt_ops over to the operations you support at an
> arbitrary time, you are in dom-0, which has an explicitly unmaintained
> and unstable interface to Xen (therefore not even likely a topic of
> discussion here), or you are in a trusted domain, which also doesn't
> need to do anything super special at "event zero".
The fact that a PV guest wants to be in ring 0 shouldn't make much
difference to how it boots; it will still want to go through the normal
PV boot path. The dom0 stuff isn't a part of this discussion, but a
dom0 kernel still boots like any other, and in general the pv ops will
be the same overall.
> The only use for the alternate entry point is to avoid running code
> with paging disabled, which is not virtualizable under Xen. Here's a
> no-brainer proposal - check the PE bit in CR0 to see if paging is
> already turned on, then jump to the alternate pv_startup32.
Seems a bit ad-hoc.
J
