Igor Mammedov <imamm...@redhat.com> writes: > On Fri, 12 Feb 2021 16:26:03 +0100 > Vitaly Kuznetsov <vkuzn...@redhat.com> wrote: > >> Vitaly Kuznetsov <vkuzn...@redhat.com> writes: >> >> > Igor Mammedov <imamm...@redhat.com> writes: >> > >> >> >> >> Please try reusing scratch CPU approach, see >> >> kvm_arm_get_host_cpu_features() >> >> for an example. You will very likely end up with simpler series, >> >> compared to reinventing wheel. >> > >> > Even if I do that (and I serioulsy doubt it's going to be easier than >> > just adding two 'u64's, kvm_arm_get_host_cpu_features() alone is 200 >> > lines long) this is not going to give us what we need to distinguish >> > between >> > >> > 'hv-passthrough,hv-evmcs' >> > >> > and >> > >> > 'hv-passthrough' >> > >> > when 'hv-evmcs' *is* supported by the host. When guest CPU lacks VMX we >> > don't want to enable it unless it was requested explicitly (former but >> > not the later). >> >> ... and if for whatever reason we decide that this is also bad/not >> needed, I can just drop patches 16-18 from the series (leaving >> 'hv-passthrough,hv-feature=off' problem to better times). > that's also an option, > we would need to make sure that hv-passthrough is mutually exclusive > with ''all'' other hv- properties to avoid above combination being > ever (mis)used.
That's an option to finally get these patches merged, not a good option for end users. 'hv-passthrough,hv-feature' works today and it's useful. Should we drop it? 'hv-passthrough/hv-default' and 'hv-passthrough/hv-default,hv-evmcs' should give us sane results. 'hv-passthrough,hv-feature=off' is convenient. Why droppping this all? To save 9 (nine) lines of code in the parser? -- Vitaly