qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).