On 12/09/2019 10:11, Jan Beulich wrote: > On 12.09.2019 10:36, Andrew Cooper wrote: >> On 12/09/2019 09:19, Jan Beulich wrote: >>> On 11.09.2019 22:05, Andrew Cooper wrote: >>>> The purpose of this change is to stop using xc_cpuid_do_domctl(), and to >>>> stop >>>> basing decisions on a local CPUID instruction. This is not an appropriate >>>> way >>>> to construct policy information for other domains. >>>> >>>> Obtain the host and domain-max policies from Xen, and mix the results as >>>> before. Provide rather more error logging than before. >>> And this passing through of host values is meant to stay long >>> term? Shouldn't this rather be passing through of max-policy >>> values, with max-policy long term wider than default-policy? The >>> change itself looks good to me, but before giving my R-b I'd >>> like to understand this aspect. >> There is a very large amount wrong with xc_cpuid_set(). >> >> For one, its behaviour is only useful for feature leaves, but it will >> operate on any leaves the user requests, and while it is capable of >> returning errors, libxl doesn't check the return value and continues >> blindly forwards. >> >> Also from the L1TF embargo days is a series of work (or at least, the >> start of) which is a total overhaul of how libxl and libxc interact when >> it comes CPUID and MSR settings. Neither xc_cpuid_set() nor >> xc_cpuid_apply_policy() will survive to the end. >> >> For now, I've opted with not changing the semantics of the calls while >> altering the data-transfer mechanism, to avoid conflating the two areas >> of work. > And with this then, as promised, > Reviewed-by: Jan Beulich <jbeul...@suse.com>
Thanks. I'll expand the commit message with a note about this. It will likely be helpful for future people doing code archaeology. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
