All of lore.kernel.org
 help / color / mirror / Atom feed
From: John David Anglin <dave.anglin@bell.net>
To: Helge Deller <deller@gmx.de>,
	linux-parisc@vger.kernel.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH][RFC] parisc: Use local tlb purges only on PA2.0 machines
Date: Tue, 27 Sep 2022 18:06:04 -0400	[thread overview]
Message-ID: <8a3451ca-cd30-4730-b7b2-bce7fdc47682@bell.net> (raw)
In-Reply-To: <efb7b1fa-f593-3c52-c8b2-cd42c2594848@gmx.de>

On 2022-09-27 4:06 p.m., Helge Deller wrote:
> On 9/25/22 22:28, John David Anglin wrote:
>> On 2022-09-25 4:11 p.m., Helge Deller wrote:
>>> n 9/25/22 22:02, John David Anglin wrote:
>>>> On 2022-09-25 2:57 p.m., Helge Deller wrote:
>>>>> +#ifdef CONFIG_PA20
>>>>> +#define ALT_COND_PACACHE    ALT_COND_ALWAYS
>>>>> +#else
>>>>> +#define ALT_COND_PACACHE    ALT_COND_NO_SMP
>>>>> +#endif
>>>>> +
>>>>>   ENTRY_CFI(flush_tlb_all_local)
>>>>>       /*
>>>>>        * The pitlbe and pdtlbe instructions should only be used to
>>>>> @@ -539,15 +545,10 @@ ENTRY_CFI(copy_user_page_asm)
>>>>>
>>>>>       /* Purge any old translations */
>>>>>
>>>>> -#ifdef CONFIG_PA20
>>>>> -    pdtlb,l        %r0(%r28)
>>>>> -    pdtlb,l        %r0(%r29)
>>>>> -#else
>>>>>   0:    pdtlb        %r0(%r28)
>>>>>   1:    pdtlb        %r0(%r29)
>>>>> -    ALTERNATIVE(0b, 0b+4, ALT_COND_NO_SMP, INSN_PxTLB)
>>>>> -    ALTERNATIVE(1b, 1b+4, ALT_COND_NO_SMP, INSN_PxTLB)
>>>>> -#endif
>>>>> +    ALTERNATIVE(0b, 0b+4, ALT_COND_PACACHE, INSN_PxTLB)
>>>>> +    ALTERNATIVE(1b, 1b+4, ALT_COND_PACACHE, INSN_PxTLB)
>>>> This doesn't look correct.  If ALT_COND_PACACHE is defined as ALT_COND_NO_SMP, the pdtlb
>>>> instructions will be converted to pdtlb,l instructions when running UP.  These are not supported
>>>> on PA 1.1.
>>>
>>> Your concern is correct, but there is an additonal check in the alternative-coding,
>>> which prevents enabling the local flag if we're not running on a PA2.0 CPU.
>>> So, those ALTERNATIVE() macros will only apply on PA2.0 machines.
>> You are correct.  Missed that.
>>
>> That only leaves the bus serialization issue when pdtlb is used on an SMP machine.
>
> I think we are Ok with what's in the kernel already.
>
> According to arch/parisc/include/asm/pgtable.h:
>
> * This is for the serialization of PxTLB broadcasts. At least on the N class
>  * systems, only one PxTLB inter processor broadcast can be active at any one
>  * time on the Merced bus. */
> extern spinlock_t pa_tlb_flush_lock;
> #if defined(CONFIG_64BIT) && defined(CONFIG_SMP)
> extern int pa_serialize_tlb_flushes;
> #else
> #define pa_serialize_tlb_flushes        (0)
> #endif
>
> we currently do TLB serialization on 64-bit machines with a 64-bit kernel only.
> N-class machines are 64-bit-only machines which can't run a 32-bit kernel.
> So, 32-bit SMP kernels (which don't have serialization for PxTLB flushes)
> don't seem to be affected.
I don't know enough to be certain. I know the c8000/rp3440 with the Itanium/zx1 CPU/memory
bus needs serialization (tried removing lock).  I suspect all machines with Runway or Runway+
CPU/memory buses need serialization.

https://www.openpa.net/bus.html#runway

The openpa site says there are some PA-7200 machines (e.g., D class)  with this bus.  They would be 32-bit only.

Dave

-- 
John David Anglin  dave.anglin@bell.net


  reply	other threads:[~2022-09-27 22:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-25 18:57 [PATCH][RFC] parisc: Use local tlb purges only on PA2.0 machines Helge Deller
2022-09-25 20:02 ` John David Anglin
2022-09-25 20:11   ` Helge Deller
2022-09-25 20:28     ` John David Anglin
2022-09-27 20:06       ` Helge Deller
2022-09-27 22:06         ` John David Anglin [this message]
2022-09-28  9:25           ` Helge Deller

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=8a3451ca-cd30-4730-b7b2-bce7fdc47682@bell.net \
    --to=dave.anglin@bell.net \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=deller@gmx.de \
    --cc=linux-parisc@vger.kernel.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.