[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 09/12] xen: add runtime parameter access support to hypfs
On 04.03.2020 17:31, Jürgen Groß wrote: > On 04.03.20 16:19, Jan Beulich wrote: >> On 04.03.2020 16:07, Jürgen Groß wrote: >>> On 04.03.20 12:32, Jan Beulich wrote: >>>> On 26.02.2020 13:47, Juergen Gross wrote: >>>>> +static void update_ept_param_append(const char *str, int val) >>>>> +{ >>>>> + char *pos = opt_ept_setting + strlen(opt_ept_setting); >>>>> + >>>>> + snprintf(pos, sizeof(opt_ept_setting) - (pos - opt_ept_setting), >>>>> + ",%s=%d", str, val); >>>>> +} >>>>> + >>>>> +static void update_ept_param(void) >>>>> +{ >>>>> + snprintf(opt_ept_setting, sizeof(opt_ept_setting), "pml=%d", >>>>> opt_ept_pml); >>>>> + if ( opt_ept_ad >= 0 ) >>>>> + update_ept_param_append("ad", opt_ept_ad); >>>> >>>> This won't correctly reflect reality: If you look at >>>> vmx_init_vmcs_config(), even a negative value means "true" here, >>>> unless on a specific Atom model. I think init_ept_param() wants >>>> to have that erratum workaround logic moved there, such that >>>> you can then assme the value to be non-negative here. >>> >>> But isn't not mentioning it in the -1 case correct? -1 means: do the >>> correct thing on the current hardware. >> >> Well, I think the output here should represent effective settings, > > The minimum requirement is to reflect the effective parameters, like > cmdline is doing for boot-time only parameters. With runtime parameters > we had no way of telling what was set, and this is now possible. > >> and a sub-item should be suppressed only if a setting has no effect >> at all in the current setup, like ... >> >>>>> + if ( opt_ept_exec_sp >= 0 ) >>>>> + update_ept_param_append("exec-sp", opt_ept_exec_sp); >>>> >>>> I agree for this one - if the value is still -1, it has neither >>>> been set nor is its value of any interest. >> >> ... here. > > I think we should not mix up specified parameters and effective > settings. In case an effective setting is of common interest it should > be reported via a specific node (like e.g. specific mitigation settings > where the cmdline is not providing enough details). But then a boolean option that wasn't specified on the command line should produce no output at all. And hence we'd need a way to tell whether an option was set from command line for _all_ of them. I don't think this would be very helpful. I'm curious if anyone else has any opinion either way (or yet another one) here: Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |