From: Igor Mammedov <imammedo@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Eduardo Habkost <ehabkost@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: Thu, 7 Dec 2017 17:48:32 +0100 [thread overview]
Message-ID: <20171207174832.42663bef@redhat.com> (raw)
In-Reply-To: <CAFEAcA-auykOKQbNcoQooNGk7Vb3wt7TH7AMA689xEj22_6KcQ@mail.gmail.com>
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
> it just once and cache the answer. Can I rely on something or other
> having the BQL or otherwise ensuring that two threads don't run
> the instance_init method in parallel (eg in a hotplug situation),
> or do I need to create and use my own mutex to protect the cached
> answer data?
considering cached data shouldn't change during qemu lifetime it
shouldn't be possible for instance_init() to clash at hotplug
time as object_new(cpu) calls serialized within monitor/qmp loop.
But why cpu's instance_init, we could cache host's value at
configure_accelerator() time (could be different depending on accel).
CCing Eduardo as he is the one who worked on -cpu max for x86
(If I recall correctly)
>
> thanks
> -- PMM
>
next prev parent reply other threads:[~2017-12-07 16:48 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 [this message]
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
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=20171207174832.42663bef@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.