[Xen-devel] Naming things (was XEN_SYSCTL_get_cpuid_policy)

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

All,

Having finally got back to some CPUID work, I've come back to a naming
problem I've been unable to resolve in the intervening time.

Originally, the plan was to introduce XEN_SYSCTL_get_cpuid_policy and
XEN_DOMCTL_{get,set}_cpuid_policy, which was shortly followed by similar
MSR policy calls.

However, to do the hypervisor side audit, the domain set cpuid and msr
policy calls have to be done together, so all state can be cross-checked
together.

Therefore, I was thinking of something more along the lines of
XEN_DOMCTL_{get,set}_arch_config to be rather more generic, and prevent
the need to add a new get/set hypercall pair for each class of
information.  However, that name is confusing with struct
xen_arch_domainconfig arch_config as part of the createdomain call.

So, XEN_DOMCTL_{get,set}_arch_settings ?

Also, is this the kind of thing which would be useful on ARM?  Its
intended for the things settings which are essentially variable for the
domain, based on the admins choice.  One usecase Jan has proposed is the
ability for a one-time action where the admin has done an update (e.g.
taken the Spectre Microcode) and wants to bump up the visible featureset
in the guest, knowing that the guest has a mechanism to detect and adapt
to the new features.  (I realise this description is a bit woolly).

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel