Rusty Russell wrote:
> As you can see in my patch, I chose an even *simpler* route: (1) then
> call paravirts[%ebx]->init(paravirts[%ebx]), which does the rest.
1) setup C running environment, 2) install paravirt_ops, then 3) call
pvo.init, then 4) start_kernel. Doesn't look any simpler to me, and
that's assuming the hypervisor is cooperative.
> Since
> this deliberately only uses %eax and %ebx, I can't see anyone having
> issues with this.
Well, it doesn't work if the hypervisor wants to use eax/ebx for
something else or nothing at all. If the hypervisor doesn't conform to
this model for whatever reason, it still needs to arrange to run some
code before getting to the pv_startup.
> When combined with Zach's "share startup_32" patch, I
> think it's a no-brainer.
>
Actually, that's a non-starter. It won't work if the kernel is running
in ring 0.
> As far as who controls the magic numbers, the answer is simple:
> whatever's in the mainline kernel. I'm happy to maintain them, and push
> numbers into mainline even if the implementation isn't.
>
But that just means they're random constants local to the kernel; if
they're only local to the kernel then they needn't exist at all. What
you're proposing is basically a hypervisor->kernel ABI. For that to be
useful, the hypervisor side of the ABI needs to play along; if they
don't, its just unnecessary crud.
J
