Zachary Amsden wrote:
> We don't need such a structure at all, and if you think really hard
> about it, Xen really doesn't either. Why does the domain builder need
> to know the hypercall page from a static string in the kernel? That
> seems completely backwards. Shouldn't the hypervisor be telling the
> guest about the hypercall page, not the other way around?
Don't see why. There are definite benefits to having the hypercall page
at a fixed address within the kernel, so you can just use an absolute
call/jmp into it.
> And why can't you check compatibility in your own hypervisor specific
> way inside your own hypervisor specific initialization routine,
> instead of putting this string table in the binary?
No, that's complicated and messy. If the kernel starts running and then
finds that the hypervisor can't support it (or vice versa), then you
need to quit and report something meaningful to the user about what went
wrong. At that point its quite likely the domain launch process has
probably gone async, so it complicates getting the error out. It much
simpler if the builder can quickly determine whether the kernel is
likely to work with a simple test at the start, and give a useful
failure reason.
> It's just messy, and looks rife to evolve in non-deterministic ways,
> as checking for the presence of arbitrary strings seems posed for a
> forward / backward compatibility nightmare - so I think you need to
> ask yourselves - is it really a good idea to put into Linux?
It's not an arbitrary string; it has a specific structure. I don't like
its current form much either, but there's no reason why there couldn't
be a sane alternative.
Also, because Xen supports more operating systems than just Linux, it
would be helpful to us to not have a proliferation of OS-specific
startup mechanisms. That's by the by; if a Linux-specific entry would
really help clean things up/simplify things, then that's OK, but I
wouldn't want to introduce difference for the sake of it.
J
