Zachary Amsden wrote:
> 1) A set_fixmap_top paravirt op - which doesn't work so well, since
> all paravirt subops need to re-use the same callouts to Linux, so
> there are twice (3x, 4x...) as many points to change if the Linux API
> changes.
>
> 2) A get_fixmap_top paravirt op - which allows the common code to just
> always set the fixmap in the normal startup routine, and also works
> for native by just returning 0xffffe000 (or should it be 0x00000000)?
>
> 3) Pass the information in at boot, or via a special argument /
> environment page.
>
> I like #2, since it seems most logical, and doesn't preclude doing #3
> later if we decide to create such a arg / envp page.
Well, I was thinking option #4: the hypervisor setup code calls
set_fixmap_top() as part of its setup (ie, when it fills out the
paravirtops structure). That way the hypervisor-specific code can use
whatever mechanism it wants to get that value, and if the hypervisor
doesn't care about the value (because it doesn't need to reserve address
space, as in 32-on-64) it needn't call anything, and the default Linux
value will stand.
I guess it's almost exactly equivalent to #2, except we don't need to
define another paravirt interface.
J
