[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine t
From: |
Eduardo Habkost |
Subject: |
Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types |
Date: |
Tue, 5 Jan 2021 13:19:12 -0500 |
On Tue, Jan 05, 2021 at 05:31:41PM +0100, Igor Mammedov wrote:
> On Tue, 5 Jan 2021 09:34:31 -0500
> Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> > On Tue, Jan 05, 2021 at 12:36:50AM +0100, Igor Mammedov wrote:
> > > On Mon, 4 Jan 2021 13:29:06 -0500
> > > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > >
> > > > On Mon, Jan 04, 2021 at 01:54:32PM +0100, Vitaly Kuznetsov wrote:
> > > > > Igor Mammedov <imammedo@redhat.com> writes:
> > > > >
> > > > > >> >
> > > > > >> > + /* Hyper-V features enabled with 'hyperv=on' */
> > > > > >> > + x86mc->default_hyperv_features = BIT(HYPERV_FEAT_RELAXED) |
> > > > > >> > + BIT(HYPERV_FEAT_VAPIC) | BIT(HYPERV_FEAT_TIME) |
> > > > > >> > + BIT(HYPERV_FEAT_CRASH) | BIT(HYPERV_FEAT_RESET) |
> > > > > >> > + BIT(HYPERV_FEAT_VPINDEX) | BIT(HYPERV_FEAT_RUNTIME) |
> > > > > >> > + BIT(HYPERV_FEAT_SYNIC) | BIT(HYPERV_FEAT_STIMER) |
> > > > > >> > + BIT(HYPERV_FEAT_FREQUENCIES) |
> > > > > >> > BIT(HYPERV_FEAT_REENLIGHTENMENT) |
> > > > > >> > + BIT(HYPERV_FEAT_TLBFLUSH) | BIT(HYPERV_FEAT_EVMCS) |
> > > > > >> > + BIT(HYPERV_FEAT_IPI) | BIT(HYPERV_FEAT_STIMER_DIRECT);
> > > > > >> >
> > > > > > I'd argue that feature bits do not belong to machine code at all.
> > > > > > If we have to involve machine at all then it should be a set
> > > > > > property/value pairs
> > > > > > that machine will set on CPU object (I'm not convinced that doing it
> > > > > > from machine code is good idea though).
> > > > > >
> > > > >
> > > > > These are 'features' and not feature bits. 'Bits' here are just our
> > > > > internal (to QEMU) representation of which features are enable and
> > > > > which
> > > > > are not, we could've just used booleans instead. These feature, when
> > > > > enabled, will result in some CPUID changes (not 1:1) but I don't see
> > > > > how
> > > > > it's different from
> > > > >
> > > > > " -machine q35,accel=kvm "
> > > > >
> > > > > which also results in CPUID changes.
> > > >
> > > > This is a good point, although having accel affect CPUID bits was
> > > > also a source of complexity for query-cpu-model-expansion and
> > > > other QMP queries.
> > >
> > > why was, it's still a headache (mutating CPU models depending on
> > > accelerator)
> > >
> > > >
> > > > >
> > > > > The main reason for putting this to x86 machine type is versioning, as
> > > > > we go along we will (hopefully) be implementing more and more Hyper-V
> > > > > features but we want to provide 'one knob to rule them all' but do it
> > > > > in
> > > > > a way that will allow migration. We already have 'hv_passthrough' for
> > > > > CPU.
> > > >
> > > > I agree completely that the set of bits needs to be on
> > > > MachineClass. We just need to agree on the external interface.
> > > That's where I disagree,
> > > let me exaggerate for demo purpose:
> > > - let's move all CPU models feature defaults to MachineClass and forget
> > > about compat properties
> > > since in that case we can opencode changes in machine_class_init
> >
> > I don't see your point here. compat_props is also part of
> > MachineClass.
> they are but compat_props are data and we typically use them for
> keeping old behavior for devices, all it needs is adding a line
> to set old property value.
> While class_init is typically used for altering machine specific
> behavior, sure it can be used to patch up device but that's
> a bit more ugly (need to add a field to MachineClass to key off
> and the somehow wire it up to affected device).
I was not excluding compat_props when I said "the set of bits
needs to be on MachineClass", so I don't think we disagree in
this specific point. (Except that I don't think non-compat_props
solution will be necessarily ugly)
>
> > >
> > > It's rather hard code integration between device models, which we try
> > > to avoid and still refactoring QEMU code to get rid of it.
> > > (sure it works until it's not and someone else need to rewrite half of
> > > QEMU
> > > to accomplish it's own task because we mixed things together)
> >
> > I don't see why using a X86CPU-specific API that is not based on
> > QOM properties is hard code integration. compat_props is not the
> > only allowed API for machines to communicate with devices.
> >
> > >
> > > >
> > > > >
> > > > > >> >
> > > > > >> > + if (x86ms->hyperv_enabled) {
> > > > > >> > + feat = x86mc->default_hyperv_features;
> > > > > >> > + /* Enlightened VMCS is only available on Intel/VMX */
> > > > > >> > + if (!cpu_has_vmx(&cpu->env)) {
> > > > > >> > + feat &= ~BIT(HYPERV_FEAT_EVMCS);
> > > > > >> > + }
> > > > > >> > +
> > > > > >> > + cpu->hyperv_features |= feat;
> > > > > > that will ignore features user explicitly doesn't want,
> > > > > > ex:
> > > > > > -machine hyperv=on -cpu foo,hv-foo=off
> > > > > >
> > > > >
> > > > > Existing 'hv_passthrough' mode can also affect the result.
> > > > > Personally, I
> > > > > don't see where 'hv-foo=off' is needed outside of debugging and these
> > > > > use-cases can probably be covered by explicitly listing required
> > > > > features but I'm not against making this work, shouldn't be hard.
> > > >
> > > > I'm all for not wasting time supporting use cases that are not
> > > > necessary in practice. We just need to document the expected
> > > > behavior clearly, whatever we decide to do.
> > >
> > > documenting is good, but if it adds new semantics to how CPU features are
> > > handled
> > > users up the stack will need code it up as well and juggle with
> > > -machine + -cpu + -device cpu-foo
> > > not to mention poor developers who will have to figure out why we do
> > > set CPU properties in multiple different ways.
> > >
> > > however if we add it as CPU properties that behave the same way as other
> > > properties, all mgmt has to do is expose new property to user for usage.
> >
> > I think we need to be careful here. Sometimes just exposing the
> > QOM properties used to implemented a feature is not the best user
> > interface. e.g.: even if using compat_props for implementing the
> > hyperv features preset, that doesn't automatically mean we want
> > hyperv=on to be a -cpu option.
> >
> > I would even argue we shouldn't be focusing on implementation
> > details (like we are doing right now) until the desired external
> > interface is described clearly.
> >
> > >
> > > it even more true when building machine from QMP interface would be
> > > available,
> > > where we would want '-device foo' more or less the same way instead of
> > > special casing some of them, i.e. I'd rather have one device to configure,
> > > instead of doing it in multiple places. It's not possible in reality
> > > but for new code we should try to minimize split brain issues.
> >
> > Is split brain a practical problem here? If the new behavior is
> > implemented in x86_cpu_realizefn() or x86_cpu_pre_plug(), we know
> > it's going to affect all CPU objects.
>
> i was talking about user interface here, i.e.:
> (QMP) create_machine(hyperv=on)
> (QMP) device_add(cpu, hv_foo=x)
> vs:
> (QMP) device_add(cpu, hyperv_defaults=on,=onhv_foo=x)
>
> i.e. in the later case cpu specific options are consolidate within device
> stanza
> and mgmt doesn't need to be aware and split cpu config in to steps.
This might make sense for this feature. I just worry that one
day we might need to make a machine option to affect CPUID
feature flags, requiring us to make this work somehow. (If we
decide to go with "-cpu hyperv=on", we can postpone that
discussion, though)
>
>
> > >
> > > > >
> > > > > > not sure we would like to introduce such invariant,
> > > > > > in normal qom property handling the latest set property should have
> > > > > > effect
> > > > > > (all other invariants we have in x86 cpu property semantics are
> > > > > > comming from legacy handling
> > > > > > and I plan to deprecate them (it will affect x86 and sparc cpus) so
> > > > > > CPUs will behave like
> > > > > > any other QOM object when it come to property handling)
> > > > > >
> > > > > > anyways it's confusing a bit to have cpu flags to come from 2
> > > > > > different places
> > > > > >
> > > > > > -cpu hyperv-use-preset=on,hv-foo=off
> > > > > >
> > > > > > looks less confusing and will heave expected effect
> > > > > >
> > > > >
> > > > > Honestly, 'hyperv-use-preset' is confusing even to me :-)
> > > > >
> > > > > What if we for a second stop thinking about Hyper-V features being CPU
> > > > > features only, e.g. if we want to create Dynamic Memory or PTP or any
> > > > > other Hyper-V specific device in a simple way? We'll have to put these
> > > > > under machine type.
> > > >
> > > > I agree. Hyper-V is not just a set of CPU features.
> > > me too,
> > > however in this case we are talking about a set of cpu features,
> > > if there is no way to implement it as cpu properties + compat properties
> > > and requires opencodding it within machine code it might be fine
> > > but I fail to see a very good reason for doing that at this momment.
> >
> > The reason would be just simplicity of implementation.
> aside other issues,
> cpu props + compact_props looks simpler than machine based variant.
Possibly the compat_props solution will be simpler if we choose
the "-cpu hyperv=on" path. I don't expect it to be simpler if we
choose the "-machine hyperv=on" path. Maybe that's our main
source of disagreement (which will go away if we go with
"-cpu hyperv=on").
Both user interface approaches (-cpu -machine) look good enough
to me as long as their behavior is documented and makes sense.
Even better if they have automated test cases.
>
> >
> > I understand there are reasons to suggest using compat_props if
> > it makes things simpler, but I don't see why we would reject a
> > patch because the implementation is not based purely on
> > compat_props.
> main issue is that patch introduces new semantics to cpu feature
> parsing.
> compat_props is for consistency with how we typically handle device
> compatibility, which is also good enough reason.
Is this point about the implementation, or about the user
interface?
>
> > I will let Vitaly to decide how to proceed, based on our
> > feedback. I encourage him to use compat_props like you suggest,
> > but I don't plan to make this a requirement.
> >
> > >
> > > >
> > > > Also, those two approaches are not mutually exclusive.
> > > > "-machine hyperv=on" can be implemented internally using
> > > > "hyperv-use-preset=on" if necessary. I don't think it has to,
> > > > however.
> > >
> > >
> >
>
--
Eduardo
Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Igor Mammedov, 2021/01/04
- Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Vitaly Kuznetsov, 2021/01/05
- Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Igor Mammedov, 2021/01/05
- Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Vitaly Kuznetsov, 2021/01/05
- Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Igor Mammedov, 2021/01/06
- Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Vitaly Kuznetsov, 2021/01/06
- Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Igor Mammedov, 2021/01/06
- Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Eduardo Habkost, 2021/01/06
- Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Vitaly Kuznetsov, 2021/01/07
Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types, Eduardo Habkost, 2021/01/06