All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Sergey Fedorov <serge.fdrv@gmail.com>, qemu-devel@nongnu.org
Cc: sergey.fedorov@linaro.org, alex.bennee@linaro.org
Subject: Re: [Qemu-devel] [PATCH] atomics: add volatile_read/volatile_set
Date: Mon, 18 Jul 2016 19:58:28 +0200	[thread overview]
Message-ID: <67224898-07f6-d7a1-283f-a764f51a4993@redhat.com> (raw)
In-Reply-To: <578D1285.8060303@gmail.com>



On 18/07/2016 19:31, Sergey Fedorov wrote:
> On 18/07/16 20:28, Paolo Bonzini wrote:
>>
>> On 18/07/2016 19:25, Sergey Fedorov wrote:
>>>>> @@ -753,14 +753,14 @@ static inline void cpu_get_invalid_tb_cpu_state(target_ulong *pc,
>>>>>                                                  target_ulong *cs_base,
>>>>>                                                  uint32_t *flags)
>>>>>  {
>>>>> -    *cs_base = -1; /* npc must be a multible of 4 */
>>>>> +    *flags = TB_FLAG_MMU_MASK;
>>>>>  }
>>> Hmm, not sure if it is really simpler to follow. Maybe " |= 1;" anyway?
>> |= 1 has the problem that tb_mark_invalid doesn't pass TB's tuple into
>> cpu_get_invalid_tb_cpu_state, and I didn't want to change that.  I'll
>> add a comment,
>>
>>     /* TB_FLAG_MMU_MASK is not a valid MMU index, which makes it is an
>>      * impossible flag combination for valid TBs.
>>      */
>>
> 
> I wonder if using a dedicated field to mark TBs invalid would be so slow
> that we couldn't afford it...

We could, but it would be slower too. :)

"Just make flags=-1 invalid" is probably a valid one too.  There are
many ways to implement it: use less than 32 bits (or equivalently
reserve one bit for invalid TBs), ensure some combos are invalid, etc.
It would probably be valid for all current targets, since no one uses 32
bits.  ARM is the closest to exhausting flag space probably.

Still, I like your patches very much so I'd like to proceed with them,
only with some changes to fix compilation on 32-bit hosts.

Paolo

  reply	other threads:[~2016-07-18 17:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-18 14:17 [Qemu-devel] [PATCH] atomics: add volatile_read/volatile_set Paolo Bonzini
2016-07-18 16:52 ` Sergey Fedorov
2016-07-18 16:53   ` Paolo Bonzini
2016-07-18 16:57     ` Sergey Fedorov
2016-07-18 17:00       ` Paolo Bonzini
2016-07-18 17:07         ` Sergey Fedorov
2016-07-18 17:11           ` Paolo Bonzini
2016-07-18 17:17             ` Sergey Fedorov
2016-07-18 17:22               ` Paolo Bonzini
2016-07-18 17:25                 ` Sergey Fedorov
2016-07-18 17:28                   ` Paolo Bonzini
2016-07-18 17:31                     ` Sergey Fedorov
2016-07-18 17:58                       ` Paolo Bonzini [this message]
2016-07-18 19:04                         ` Sergey Fedorov
2016-07-18 20:54                           ` 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=67224898-07f6-d7a1-283f-a764f51a4993@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=serge.fdrv@gmail.com \
    --cc=sergey.fedorov@linaro.org \
    /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.