From: Peter Xu <peterx@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, Laurent Vivier <lvivier@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 3/6] migration: move global_state.optional out
Date: Mon, 19 Jun 2017 14:31:10 +0800 [thread overview]
Message-ID: <20170619063110.GA16787@pxdev.xzpeter.org> (raw)
In-Reply-To: <20170616143432.GO5016@thinpad.lan.raisama.net>
On Fri, Jun 16, 2017 at 11:34:32AM -0300, Eduardo Habkost wrote:
> On Fri, Jun 16, 2017 at 03:58:20PM +0800, Peter Xu wrote:
> > On Tue, Jun 13, 2017 at 08:16:35AM -0300, Eduardo Habkost wrote:
[...]
> > Hi, Eduardo,
> >
> > I'm working on providing a AccelState.global_props, then let KVM/TCG
> > to use it to handle X86_CPU properties there. However, I stuck at a
> > point where TCG/KVM cannot know what is the macro "TYPE_X86_CPU"
> > (since it's only there on X86). The change is something like this (it
> > cannot be applied directly to master since it's only one patch among
> > my series, it is used to show what I am doing and the problem):
>
> Unfortunately TYPE_X86_CPU macro is arch-specific because it may
> be expanded to "x86_64-cpu" or "i386-cpu" depending on the QEMU
> target. So it actually represents two different classes, because
> the target/i386/cpu.c code is compiled twice (once for i386 and
> once for x86_64).
>
> In this case, you will need two entries on the tcg default
> property list:
>
> x86_64-cpu.vme=off
> i386-cpu.vme=off
>
> Now, we could hardcode the class names, or provide TYPE_I386_CPU
> and TYPE_X86_64_CPU macros from a header available to generic
> code[1]. I don't know what's the best solution.
>
> [1] i.e. not cpu.h. I was going to suggest including
> "target/i386/cpu-qom.h", but I'm not sure if
> it can be safely included by generic code.
Thanks. I'll choose to hard code it for now (with some comments).
>
> >
> > --8<--
> > diff --git a/accel.c b/accel.c
> > index 82b318c..db503b6 100644
> > --- a/accel.c
> > +++ b/accel.c
> > @@ -34,13 +34,34 @@
> > #include "sysemu/qtest.h"
> > #include "hw/xen/xen.h"
> > #include "qom/object.h"
> > +#if TARGET_I386
> > +#include "target/i386/cpu-qom.h"
> > +#endif
> >
> > int tcg_tb_size;
> > static bool tcg_allowed = true;
> >
> > +static AccelPropValue x86_tcg_default_props[] = {
> > + { "vme", "off" },
> > + { NULL, NULL },
>
> You need a "driver" (type) field too. I suggest using struct
> GlobalProperty like we do on MachineClass.
Yeah, I did it ...
>
> > +};
> > +
> > +static void tcg_register_accel_props(AccelState *accel)
> > +{
> > +#if TARGET_I386
> > + AccelPropValue *entry;
> > +
> > + for (entry = x86_tcg_default_props; entry->prop; entry++) {
> > + global_property_list_register(accel->global_props, TYPE_X86_CPU,
> > + entry->prop, entry->value, false);
... here, since the driver field is the same (we'll just apply this
property list to both "i386-cpu" and "x86_64-cpu").
> > + }
> > +#endif
> > +}
> > +
[...]
> > What above patch did is something like "moving x86_cpu properties from
> > x86 CPU codes into tcg" (I am using tcg as example, kvm is more
> > complex but has similar issue).
> >
> > Here the general problem is that, there are some properties to be
> > applied when both conditions match:
> >
> > - target is X86 (so using X86 cpus)
> > - accel is tcg
> >
> > In the old code, it works since in x86 cpu.c codes we can use this:
> >
> > if (tcg_enabled()) {
> > x86_cpu_apply_props(cpu, tcg_default_props);
> > }
> >
> > to know "whether accel is TCG". However I cannot do similar thing in
> > TCG code to know "whether target is x86". (I was trying to use
> > TARGET_I386 but it was poisoned, of course...)
> >
> > Any thoughts? (Markus/Paolo/others?)
>
> You don't need to make the property conditional on the target, if
> you just use the right class name on the "driver' field.
Yeah, as long as I can use the hard coded "i386-cpu"/"x86_64-cpu" in
accelerator codes, then I'll be fine. Thanks again!
--
Peter Xu
next prev parent reply other threads:[~2017-06-19 6:31 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-09 3:48 [Qemu-devel] [PATCH v2 0/6] migration: objectify MigrationState Peter Xu
2017-06-09 3:48 ` [Qemu-devel] [PATCH v2 1/6] machine: export register_compat_prop() Peter Xu
2017-06-09 7:41 ` Juan Quintela
2017-06-09 3:48 ` [Qemu-devel] [PATCH v2 2/6] migration: let MigrationState be a qdev Peter Xu
2017-06-09 7:42 ` Juan Quintela
2017-06-09 13:39 ` Markus Armbruster
2017-06-12 4:46 ` Peter Xu
2017-06-12 16:13 ` Eduardo Habkost
2017-06-13 3:52 ` Peter Xu
2017-06-13 11:27 ` Eduardo Habkost
2017-06-19 9:09 ` Markus Armbruster
2017-06-21 9:28 ` Peter Xu
2017-06-09 3:48 ` [Qemu-devel] [PATCH v2 3/6] migration: move global_state.optional out Peter Xu
2017-06-09 7:43 ` Juan Quintela
2017-06-09 13:40 ` Eduardo Habkost
2017-06-09 17:33 ` Juan Quintela
2017-06-12 8:18 ` Peter Xu
2017-06-13 3:41 ` Peter Xu
2017-06-13 11:16 ` Eduardo Habkost
2017-06-14 2:52 ` Peter Xu
2017-06-16 7:58 ` Peter Xu
2017-06-16 14:34 ` Eduardo Habkost
2017-06-19 6:31 ` Peter Xu [this message]
2017-06-09 3:49 ` [Qemu-devel] [PATCH v2 4/6] migration: move only_migratable to MigrationState Peter Xu
2017-06-09 7:43 ` Juan Quintela
2017-06-09 3:49 ` [Qemu-devel] [PATCH v2 5/6] migration: move skip_configuration out Peter Xu
2017-06-09 7:45 ` Juan Quintela
2017-06-09 3:49 ` [Qemu-devel] [PATCH v2 6/6] migration: move skip_section_footers Peter Xu
2017-06-09 7:47 ` Juan Quintela
2017-06-09 8:39 ` Peter Xu
2017-06-09 10:47 ` Eric Blake
2017-06-12 4:37 ` Peter Xu
2017-06-09 7:48 ` [Qemu-devel] [PATCH v2 0/6] migration: objectify MigrationState Juan Quintela
2017-06-09 8:40 ` Peter Xu
2017-06-09 14:02 ` Markus Armbruster
2017-06-09 17:30 ` Juan Quintela
2017-06-12 7:24 ` Peter Xu
2017-06-19 8:58 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170619063110.GA16787@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.