At 10:45 +0200 on 19 Oct (1603104300), Jan Beulich wrote:
> With them depending on just the number of shadow levels, there's no need
> for more than one instance of them, and hence no need for any hook (IOW
> 452219e24648 ["x86/shadow: monitor table is HVM-only"] didn't go quite
> far enough). Move the functions to hvm.c while dropping the dead
> is_pv_32bit_domain() code paths.
>
> While moving the code, replace a stale comment reference to
> sh_install_xen_entries_in_l4(). Doing so made me notice the function
> also didn't have its prototype dropped in 8d7b633adab7 ("x86/mm:
> Consolidate all Xen L4 slot writing into init_xen_l4_slots()"), which
> gets done here as well.
>
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Tim Deegan <t...@xen.org>
> TBD: In principle both functions could have their first parameter
> constified. In fact, "destroy" doesn't depend on the vCPU at all
> and hence could be passed a struct domain *. Not sure whether such
> an asymmetry would be acceptable.
> In principle "make" would also not need passing of the number of
> shadow levels (can be derived from v), which would result in yet
> another asymmetry.
> If these asymmetries were acceptable, "make" could then also update
> v->arch.hvm.monitor_table, instead of doing so at both call sites.
Feel free to add consts, but please don't change the function
parameters any more than that. I would rather keep them as a matched
pair, and leave the hvm.monitor_table updates in the caller, where
it's easier to see why they're not symmetrical.
Cheers
Tim.
