Rusty Russell wrote:
> I completely disagree with this. While it's great that Xen has a way
> of encapsulating this information, there's no good reason not to have a
> (Linux) standard way of doing so. Of course, it should work with Xen,
> too, which is why it's written the way it is...
>
> Remember, my goal differs substantially from yours and Zachs: it is to
> make writing a new hypervisor interface as simple as possible.
>
A new interface, or a new binding to the interface?
My goal is definitely to make the interface as easy to implement as
possible, while being compete and functional. I don't think we have a
disagreement here.
But I can't see how this proposal makes anything easier. It makes
writing a binding to an existing hypervisor considerably harder, but I
don't see what it improves. At best its neutral because everything does
actually conform to its model, but at worst it requires either
hypervisor modifications or individual hypervisors to use separate entry
points anyway.
In either case, it's a false abstraction which doesn't represent what's
really going on, and doesn't really help anybody. It cuts at the wrong
point.
>> It isn't clear to me who sets %ebx in your proposal.
>>
> Naah, the hypervisor sets %ebx. That's 0 for you, so it's all fine.
>
Sure, but that's just happenstance. I'm pretty sure any given
hypervisor will probably zero all the registers if they're not some
uninitialized random value.
What's more, your proposed interface doesn't pass through %esi, which is
the pointer to the startup structure passed over from Xen. Do you
propose all hypervisors pass a void * of stuff through, or that we come
up with some other way of capturing it? Or just save all the registers
off somewhere for later consumption? In either case, it adds cruft to
the interface which needn't exist at all.
> Um, Jeremy, so exactly what are you smoking? 8) Since this requires a
> reboot anyway, just put it in the new kernel. Or, if you want to do
> this without a reboot, use a module to mug paravirt_ops (not yet
> possible, but not too hard to add later). Either way, it's not today's
> problem AFAICT.
>
No, with a reboot, but we can still mug it at boot time - by changing
the entrypoint.
> But far messier to have to de-static and declare those internal
> functions. Given how many Xen wants as the default, the NULL solution
> works well. In my startup_paravirt scheme, you don't have to use it;
> it's up to your init function.
>
I disagree. Making things explicit isn't messy, it makes things clear.
Overlaying two paravirt structures is just cleverness for the sake of
it, obscuring what's really going on in order to save a few keystrokes.
>> My plan was that there would be a paravirt-foo directory for each
>> hypervisor, and a corresponding foo-specific entrypoint in head.S, which
>> would be included from foo-head.S.
>>
>
> Seems fair: if we end up with only a couple of files in those dirs we
> can always collapse them back.
>
I modeled it on the subarch stuff, which tend to have very few files in
each of the mach-* directories.
J
