On 13/09/2019 07:38, Jan Beulich wrote: > >> v2: >> * Introduce a command line option to retain old behaviour. >> * Advertise virtualised faulting support to dom0 when it is used. >> >> RFC: The previous logic was slightly buggy in that even PVH dom0's had >> virtualised faulting support hidden from them. Given that this case always >> hits the CPUID intercept, how much do we care about retaining the old >> behaviour? > I'm having trouble with this statement: Neither the description nor > the actual code change suggest you alter behavior in this regard > (i.e. with the option used PVH would still be treated the same as > PV afaict). Yet here you seem to suggest things change with this > patch. > > As to the question, I think I'd consider this a bugfix, and hence > for the behavior to be okay to change. But as per above I would > expect the change to init_domain_msr_policy() to also include > adding is_pv_domain() to the conditional, or alternatively to > override opt_dom0_cpuid_faulting to true if a PVH Dom0 is being > built.
I've pulled the bugfix out into an earlier patch so it can be backported. >> --- >> xen/arch/x86/cpu/common.c | 59 >> +++++++++++++++++++++++---------------------- >> xen/arch/x86/dom0_build.c | 2 ++ >> xen/arch/x86/msr.c | 3 ++- >> xen/include/asm-x86/setup.h | 1 + >> 4 files changed, 35 insertions(+), 30 deletions(-) > Please also update the command line doc. Hmm - I wonder where the hunk went... I did write one. > >> @@ -92,7 +93,7 @@ int init_domain_msr_policy(struct domain *d) >> return -ENOMEM; >> >> /* See comment in intel_ctxt_switch_levelling() */ >> - if ( is_control_domain(d) ) >> + if ( !opt_dom0_cpuid_faulting && is_control_domain(d) ) >> mp->platform_info.cpuid_faulting = false; > While unrelated to the overall change here, I think the comment > would better be updated too, to drop the intel_ prefix of the > function name. Fixed in the bugfix patch. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
