Zachary Amsden wrote:
> Jeremy Fitzhardinge wrote:
>> 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.
>
> We support absolute calls/jmps with our layer to addresses that can't
> be determined at link time. You could do the same.
Sure, but I'd prefer to use the linker over dynamic patching if its
simple to do so.
>> 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.
>
> Using an ELF field for the relocated kernel virtual base instead of
> (or, in addition to) embedding it in the string table is the only
> thing I strongly object to.
Thinking about it, the best way to represent that stuff is probably in a
PT_NOTE segment. That would give us flexibility without needing to pack
everything into strings (while still allowing us to have strings where
appropriate).
In general, I agree we should use standard ELF fields in standard ways
if that's the right thing to do. Are you talking about using the phdr
p_paddr/p_vaddr fields properly?
J
