On Mon, 22 Feb 2021 11:20:34 +0100 Vitaly Kuznetsov <vkuzn...@redhat.com> wrote:
> Vitaly Kuznetsov <vkuzn...@redhat.com> writes: > > > Igor Mammedov <imamm...@redhat.com> writes: > > > >>> > >>> We need to distinguish because that would be sane. > >>> > >>> Enlightened VMCS is an extension to VMX, it can't be used without > >>> it. Genuine Hyper-V doesn't have a knob for enabling and disabling it, > >> ... > >>> That bein said, if > >>> guest CPU lacks VMX it is counter-productive to expose EVMCS. However, > >>> there is a problem with explicit enablement: what should > >>> > >>> 'hv-passthrough,hv-evmcs' option do? Just silently drop EVMCS? Doesn't > >>> sound sane to me. > >> based on above I'd error out is user asks for unsupported option > >> i.e. no VMX -> no hv-evmcs - if explicitly asked -> error out > > > > That's what I keep telling you but you don't seem to listen. 'Scratch > > CPU' can't possibly help with this use-case because when you parse > > > > 'hv-passthrough,hv-evmcs,vmx=off' you > > > > 1) "hv-passthrough" -> set EVMCS bit to '1' as it is supported by the > > host. > > > > 2) 'hv-evmcs' -> keep EVMCS bit '1' > > > > 3) 'vmx=off' -> you have no idea where EVMCS bit came from. > > > > We have to remember which options were aquired from the host and which > > were set explicitly by the user. > > Igor, > > could you please comment on the above? In case my line of thought is > correct, and it is impossible to distinguish between e.g. > > 'hv-passthrough,hv-evmcs,-vmx' > and > 'hv-passthrough,-vmx' > > without a custom parser (written just exactly the way I did in this > version, for example) regardless of when 'hv-passthrough' is > expanded. E.g. we have the exact same problem with > 'hv-default,hv-evmcs,-vmx'. I that case I see no point in discussing right, if we need to distinguish between explicit and implicit hv-evmcs set by hv-passthrough custom parser probably the way to go. However do we need actually need to do it? I'd treat 'hv-passthrough,-vmx' the same way as 'hv-passthrough,hv-evmcs,-vmx' and it applies not only hv-evmcs but other features hv-passthrough might set (i.e. if whatever was [un]set by hv-passthrough in combination with other features results in invalid config, QEMU shall error out instead of magically altering host provided hv-passthrough value). something like: 'hv-passthrough,-vmx' when hv-passthrough makes hv-evmcs bit set should result in error_setg(errp,"'vmx' feature can't be disabled when hv-evmcs is enabled," " either enable 'vmx' or disable 'hv-evmcs' along with disabling 'vmx'" making host's features set, *magically* mutable, depending on other user provided features is a bit confusing. One would never know what hv-passthrough actually means, and if enabling/disabling 'random' feature changes it. It's cleaner to do just what user asked (whether implicitly or explicitly) and error out in case it ends up in nonsense configuration. > 'scratch CPUs' idea at this point because it is not going to change > anything at all ('hv_features_on' will stay, custom parsers will stay).g > > Am I missing something? >