[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 06/13] kvm: let kvm use AccelState.global_pro
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH v3 06/13] kvm: let kvm use AccelState.global_props |
Date: |
Wed, 21 Jun 2017 09:09:35 -0300 |
User-agent: |
Mutt/1.8.0 (2017-02-23) |
On Wed, Jun 21, 2017 at 11:00:54AM +0800, Peter Xu wrote:
> On Tue, Jun 20, 2017 at 11:07:34AM -0300, Eduardo Habkost wrote:
> > On Tue, Jun 20, 2017 at 09:55:03PM +0800, Peter Xu wrote:
> > > On Mon, Jun 19, 2017 at 01:14:03PM -0300, Eduardo Habkost wrote:
[...]
> >
> > >
> > > Another thing worries me a bit is that I may make things more
> > > confusing if I separate this list into two (then we'll have part of
> > > the properties in accel code, and the rest ones still in cpu.c).
> > >
> > > (then I can also avoid using hard code in accel.c/kvm.c as well, which
> > > is something I really want to stop from doing. Maybe there can be
> > > some better idea, but I cannot really figure it out now...)
> > >
> > > I'll just hold here to see whether you like above idea before moving
> > > on to further comments. Thanks,
> >
> >
> > Agreed.
> >
> > When I suggested using accel-provided global properties to
> > replace kvm_default_props, I forgot x86_cpu_change_kvm_default()
> > existed, and it makes things much more complex.
> >
> > I really really want to make the existing x2apic/svm/kvm-pv-eoi
> > compat stuff be based on static lists of properties. If we make
> > them dynamically built at runtime, we still can't introspect them
> > and it won't be worth the extra complexity.
> >
> > I believe we can still find a solution to represent the
> > x2apic/svm/kvm-pv-eoi rules using static lists, but this
> > shouldn't block the migration work you are doing.
>
> One thing I think of is:
>
> Let MachineClass::compat_props be MachCompatProp (rather than
> GlobalProperty), then define it as:
>
> struct MachCompatProp {
> GlobalProperty prop;
> bool (*prop_valid)();
> };
>
> (We may pass MigrationState *ms into prop_valid(), but for current
> requirements we may not need that, since what we need is basically
> tcg_enabled(), kvm_enabled(), or kvm_irqchip_is_split() checks)
>
> Then this property will only be delivered to the global_props list
> only if its prop_valid() check pass. Thanks,
The problem with a ->prop_valid() hook is that it's code, not
data. It means we can't represent it in the reply of a QMP
introspection command, or allow equivalent behavior to be
reproduced using command-line options.
Device-specific rules like this can be solved by a boolean compat
property implemented by the device itself. e.g.: a "auto-x2apic"
property in the x86 CPU code.
--
Eduardo
[Qemu-devel] [PATCH v3 07/13] tcg: use AccelState.global_props, Peter Xu, 2017/06/19
[Qemu-devel] [PATCH v3 08/13] trace: add qdev_global_prop_apply, Peter Xu, 2017/06/19
[Qemu-devel] [PATCH v3 09/13] migration: let MigrationState be a qdev, Peter Xu, 2017/06/19
[Qemu-devel] [PATCH v3 10/13] migration: move global_state.optional out, Peter Xu, 2017/06/19
[Qemu-devel] [PATCH v3 11/13] migration: move only_migratable to MigrationState, Peter Xu, 2017/06/19
[Qemu-devel] [PATCH v3 12/13] migration: move skip_configuration out, Peter Xu, 2017/06/19