On 13/11/2018 14:14, Jan Beulich wrote:
>>>> On 12.11.18 at 17:16, <andrew.coop...@citrix.com> wrote:
>> Currently, a number of options passed for domain creation are ignored, or
>> have
>> implicit fallback behaviour. This is bad for forwards compatibility, and for
>> end users to be certain that they got the configuration they asked for.
>>
>> With this change:
>> * ARM now strictly requires that XEN_DOMCTL_CDF_hap is passed. Previously,
>> only XEN_DOMCTL_CDF_hvm_guest was checked.
>> * For x86, requesting HAP without HVM is now prohibited, as the combination
>> makes no sense.
>> * For x86, requesting HAP on a non-HAP capable system will fail, rather than
>> silently fall back to Shadow.
>>
>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
>> ---
>> CC: Jan Beulich <jbeul...@suse.com>
>> CC: Wei Liu <wei.l...@citrix.com>
>> CC: Stefano Stabellini <sstabell...@kernel.org>
>> CC: Julien Grall <julien.gr...@arm.com>
>> CC: Ian Jackson <ian.jack...@citrix.com>
>> CC: Wei Liu <wei.l...@citrix.com>
>>
>> Semi RFC because this may cause a user-visible change in behaviour. However,
>> if the user has gone to the effort of specifying hap=1, silently falling back
>> to shadow is unexpected, and IMO, a bug.
> My view on this to a fair part depends on whether the tool stack
> would guard us from actually getting into such a situation in the
> hypervisor. Getting an unspecific -EINVAL back without further
> help towards diagnosis by the tool stack would make such a
> change undesirable imo. This also extends to other checks you
> appear to tighten - for example I wouldn't want to see a PV
> guest config with "hap=1" in it to no longer work if currently it
> happens to work, at least not without a clear hint towards the
> issue.
Hmm - in attempting to answer this, I've discovered that xl issues no
warning/error about hap or nestedhvm with type="pv", and that a PV-shim
Xen binary will be started as a PV guest, despite the domain builder
identifying the binary as PVH.
>
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -420,6 +420,46 @@ void arch_vcpu_destroy(struct vcpu *v)
>>
>> int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
>> {
>> + bool hvm;
>> +
>> + if ( !IS_ENABLED(CONFIG_PV) && !(config->flags &
>> XEN_DOMCTL_CDF_hvm_guest) )
>> + {
>> + dprintk(XENLOG_INFO, "PV support not available\n");
>> + return -EINVAL;
>> + }
>> +
>> + if ( !hvm_enabled && (config->flags & XEN_DOMCTL_CDF_hvm_guest) )
>> + {
>> + dprintk(XENLOG_INFO, "HVM support not available\n");
>> + return -EINVAL;
>> + }
>> +
>> + hvm = config->flags & XEN_DOMCTL_CDF_hvm_guest;
> Would you mind making this the initializer of the variable and using
> the variable in the two if()-s above? Personally I also think the two
> if()-s would better be folded, using a conditional expression as its
> condition.
I can move the initialiser, but how do you propose folding the
conditionals given their different contents?
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
