All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] in a device or CPU instance init/realize, can I rely on something having the BQL or equivalent?
Date: Fri, 8 Dec 2017 14:16:18 +0100	[thread overview]
Message-ID: <20171208141618.11e60846@redhat.com> (raw)
In-Reply-To: <CAFEAcA9Uh9f3UddCNiB3u6BD9Qg=sUMDmMYYn1+sryiJUMOFYg@mail.gmail.com>

On Thu, 7 Dec 2017 17:26:53 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 7 December 2017 at 17:13, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 7 December 2017 at 17:07, Eduardo Habkost <ehabkost@redhat.com> wrote:  
> >> On Thu, Dec 07, 2017 at 04:53:59PM +0000, Peter Maydell wrote:  
> >>> On 7 December 2017 at 16:48, Igor Mammedov <imammedo@redhat.com> wrote:  
> >>> > On Thu, 7 Dec 2017 16:05:50 +0000
> >>> > Peter Maydell <peter.maydell@linaro.org> wrote:
> >>> >  
> >>> >> Hi; I'm currently writing '-cpu max' support for ARM. For that I'd
> >>> >> like to be able to do the "probe host kernel for its supported feature
> >>> >> set" in the CPU object's instance-init function, but I'd like to do  
> >>
> >> I don't think instance_init is appropriate for that, as
> >> object_free(object_new(t)) must be always safe to call and free
> >> of side-effects for all types.  Wouldn't it work if you do that
> >> on realize?  
> >
> > I think we need the information before realize, but I'll double
> > check.  
> 
> We do need the information before realize, because the probe
> is what tells us what feature bits we need to set, and the
> ARM instance_post_init hook needs to look at those to determine
> eg which other feature bits to set and which QOM properties to
> expose as a result, and all that has to happen at init time,
> not realize time.
maybe it could be modeled after  kvm_ppc_register_host_cpu_type(),
i.e. create type with necessary feature bits set at cpu's class
init time (sort of combo of what ppc and x86 do).

i.e. one caches host's feature bits at cpu_class_init time and
then loads applies them to object instance at instance init time,
like in x86_cpu_initfn()->x86_cpu_load_def().

TBH:
 I do not recall why we have x86 max/host cpu types do feature
 loading at realize time instead of at class init like the rest
 of static cpu types.


> thanks
> -- PMM

  reply	other threads:[~2017-12-08 13:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-07 16:05 [Qemu-devel] in a device or CPU instance init/realize, can I rely on something having the BQL or equivalent? Peter Maydell
2017-12-07 16:48 ` Igor Mammedov
2017-12-07 16:53   ` Peter Maydell
2017-12-07 17:07     ` Eduardo Habkost
2017-12-07 17:13       ` Peter Maydell
2017-12-07 17:26         ` Peter Maydell
2017-12-08 13:16           ` Igor Mammedov [this message]
2017-12-08 13:19             ` Peter Maydell
2017-12-08 14:50               ` Igor Mammedov
2017-12-08 15:05                 ` Peter Maydell
2017-12-08 16:14                 ` Eduardo Habkost
2017-12-08 17:32                   ` Igor Mammedov
2017-12-08 17:58                     ` Eduardo Habkost

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=20171208141618.11e60846@redhat.com \
    --to=imammedo@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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.