On 12/14/21 4:16 PM, Andrew Cooper wrote:
Specifically, this lets the user opt in to non-default for dom0.Split features[] out of parse_xen_cpuid(), giving it a lightly more appropraite name, so it can be shared with parse_xen_cpuid(). Collect all dom0 settings together in dom0_{en,dis}able_feat[], and apply it to dom0's policy when other tweaks are being made. Signed-off-by: Andrew Cooper <[email protected]> --- CC: Jan Beulich <[email protected]> CC: Roger Pau Monné <[email protected]> CC: Wei Liu <[email protected]> CC: Daniel Smith <[email protected]> RFC, because I think we've got a preexisting error with late hwdom here. We really should not be cobbering a late hwdom's settings (which were provided in the usual way by the toolstack in dom0). Furthermore, the distinction gets more murky in a hyperlaunch future where multiple domains may be constructed by Xen, and there is reason to expect that a full toolstack-like configuration is made available for them.
For hyperlaunch, perhaps Christohper and I should revisit the DTB to add a cpuid field/mask where CPU features can be masked out.
One option might be to remove the special case from init_domain_cpuid_policy() and instead make a call into the cpuid code from create_dom0(). It would have to be placed between domain_create() and alloc_dom0_vcpu0() for dynamic sizing of the FPU block to work. Thoughts?
v/r, dps
