From: "Alex Bennée" <alex.bennee@linaro.org>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Robert Foley <robert.foley@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
"Emilio G. Cota" <cota@braap.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Puhov <peter.puhov@linaro.org>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH 1/2] hw/core: Add bql_interrupt flag to CPUClass
Date: Sun, 02 Aug 2020 17:05:04 +0100 [thread overview]
Message-ID: <87ime1yqxb.fsf@linaro.org> (raw)
In-Reply-To: <20200731192404.GH225270@habkost.net>
Eduardo Habkost <ehabkost@redhat.com> writes:
> On Fri, Jul 31, 2020 at 03:14:02PM -0400, Robert Foley wrote:
>> On Fri, 31 Jul 2020 at 13:44, Eduardo Habkost <ehabkost@redhat.com> wrote:
>> > >
>> > > +static inline void cpu_class_disable_bql_interrupt(CPUClass *cc)
>> > > +{
>> > > + cc->bql_interrupt = false;
>> > > +}
>> >
>> > Class data is not supposed to change outside class_init. Why do
>> > you need this function? I don't see it being used anywhere in
>> > this series.
>>
>> This function was to be called from changes in a later patch series
>> that depend on these changes. BTW, I added a correction above,
>> it should be disable, not enable. The idea is that it is initialized to true,
>> but then the per arch changes would use this call at init time to set
>> it to false
>> as needed.
>
> If you plan to call it from class_init, I don't think you need a
> wrapper. You can simply set cc->bql_interrupt=false directly
> inside arch-specific class_init functions.
We just need to be careful of the ordering so the base class init goes
first. Is that always the case?
>
> If you plan to call it from somewhere else, then maybe the field
> doesn't belong to CPUClass.
>
>>
>> We can remove this function from this series and add it in later when
>> it gets used,
>> it might make things more clear.
>
> Makes sense to me.
--
Alex Bennée
next prev parent reply other threads:[~2020-08-02 16:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 12:51 [PATCH 0/2] accel/tcg: remove implied BQL from cpu_handle_interrupt/exception path Robert Foley
2020-07-31 12:51 ` [PATCH 1/2] hw/core: Add bql_interrupt flag to CPUClass Robert Foley
2020-07-31 17:43 ` Eduardo Habkost
2020-07-31 19:14 ` Robert Foley
2020-07-31 19:24 ` Eduardo Habkost
2020-08-02 16:05 ` Alex Bennée [this message]
2020-08-04 20:36 ` Eduardo Habkost
2020-07-31 12:51 ` [PATCH 2/2] accel/tcg: interrupt/exception handling uses bql_interrupt flag Robert Foley
2020-07-31 18:02 ` Paolo Bonzini
2020-07-31 20:09 ` Robert Foley
2020-07-31 20:21 ` Paolo Bonzini
2020-08-02 16:09 ` Alex Bennée
2020-08-03 7:11 ` Paolo Bonzini
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=87ime1yqxb.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=cota@braap.org \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.puhov@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=robert.foley@linaro.org \
--cc=rth@twiddle.net \
/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).