Re: [Xen-devel] Naming things (was XEN_SYSCTL_get_cpuid_policy)

[Julien Grall <julien.grall@xxxxxxx>]

Hi Andrew,

On 02/27/2018 05:27 PM, Andrew Cooper wrote:
> 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.
I am a bit confused, it sounds like we would have two way to set 
settings for domain:
        1) At domain creation with xen_arch_domainconfig
        2) With the new hypercall later on

How a developer would choose to one over the way for his new option?

> 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).
I could potentially see a use on Arm in long term to enable/disable an 
optional features (e.g SVE, pointer authentication...).
Cheers,

--
Julien Grall

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