[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Naming things (was XEN_SYSCTL_get_cpuid_policy)


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

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).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.