devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Ghiti <alex@ghiti.fr>
To: Anup Patel <apatel@ventanamicro.com>, Conor Dooley <conor@kernel.org>
Cc: Yong-Xuan Wang <yongxuan.wang@sifive.com>,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	kvm-riscv@lists.infradead.org, kvm@vger.kernel.org,
	ajones@ventanamicro.com, greentime.hu@sifive.com,
	vincent.chen@sifive.com, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v5 2/4] dt-bindings: riscv: Add Svade and Svadu Entries
Date: Fri, 21 Jun 2024 10:37:21 +0200	[thread overview]
Message-ID: <40a7d568-3855-48fb-a73c-339e1790f12f@ghiti.fr> (raw)
In-Reply-To: <CAK9=C2XH7-RdVpojX8GNW-WFTyChW=sTOWs8_kHgsjiFYwzg+g@mail.gmail.com>

On 20/06/2024 08:25, Anup Patel wrote:
> On Wed, Jun 5, 2024 at 10:25 PM Conor Dooley <conor@kernel.org> wrote:
>> On Wed, Jun 05, 2024 at 08:15:08PM +0800, Yong-Xuan Wang wrote:
>>> Add entries for the Svade and Svadu extensions to the riscv,isa-extensions
>>> property.
>>>
>>> Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com>
>>> ---
>>>   .../devicetree/bindings/riscv/extensions.yaml | 30 +++++++++++++++++++
>>>   1 file changed, 30 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> index 468c646247aa..1e30988826b9 100644
>>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> @@ -153,6 +153,36 @@ properties:
>>>               ratified at commit 3f9ed34 ("Add ability to manually trigger
>>>               workflow. (#2)") of riscv-time-compare.
>>>
>>> +        - const: svade
>>> +          description: |
>>> +            The standard Svade supervisor-level extension for raising page-fault
>>> +            exceptions when PTE A/D bits need be set as ratified in the 20240213
>>> +            version of the privileged ISA specification.
>>> +
>>> +            Both Svade and Svadu extensions control the hardware behavior when
>>> +            the PTE A/D bits need to be set. The default behavior for the four
>>> +            possible combinations of these extensions in the device tree are:
>>> +            1. Neither svade nor svadu in DT: default to svade.
>> I think this needs to be expanded on, as to why nothing means svade.
> Actually if both Svade and Svadu are not present in DT then
> it is left to the platform and OpenSBI does nothing.
>
>>> +            2. Only svade in DT: use svade.
>> That's a statement of the obvious, right?
>>
>>> +            3. Only svadu in DT: use svadu.
>> This is not relevant for Svade.
>>
>>> +            4. Both svade and svadu in DT: default to svade (Linux can switch to
>>> +               svadu once the SBI FWFT extension is available).
>> "The privilege level to which this devicetree has been provided can switch to
>> Svadu if the SBI FWFT extension is available".
>>
>>> +        - const: svadu
>>> +          description: |
>>> +            The standard Svadu supervisor-level extension for hardware updating
>>> +            of PTE A/D bits as ratified at commit c1abccf ("Merge pull request
>>> +            #25 from ved-rivos/ratified") of riscv-svadu.
>>> +
>>> +            Both Svade and Svadu extensions control the hardware behavior when
>>> +            the PTE A/D bits need to be set. The default behavior for the four
>>> +            possible combinations of these extensions in the device tree are:
>> @Anup/Drew/Alex, are we missing some wording in here about it only being
>> valid to have Svadu in isolation if the provider of the devicetree has
>> actually turned on Svadu? The binding says "the default behaviour", but
>> it is not the "default" behaviour, the behaviour is a must AFAICT. If
>> you set Svadu in isolation, you /must/ have turned it on. If you set
>> Svadu and Svade, you must have Svadu turned off?
> Yes, the wording should be more of requirement style using
> must or may.
>
> How about this ?
> 1) Both Svade and Svadu not present in DT => Supervisor may
>      assume Svade to be present and enabled or it can discover
>      based on mvendorid, marchid, and mimpid.
> 2) Only Svade present in DT => Supervisor must assume Svade
>      to be always enabled. (Obvious)
> 3) Only Svadu present in DT => Supervisor must assume Svadu
>      to be always enabled. (Obvious)


I agree with all of that, but the problem is how can we guarantee that 
openSBI actually enabled svadu? This is not the case for now.


> 4) Both Svade and Svadu present in DT => Supervisor must
>      assume Svadu turned-off at boot time. To use Svadu, supervisor
>      must explicitly enable it using the SBI FWFT extension.
>
> IMO, the #2 and #3 are definitely obvious but still worth mentioning.
>
>>> +            1. Neither svade nor svadu in DT: default to svade.
>>> +            2. Only svade in DT: use svade.
>> These two are not relevant to Svadu, I'd leave them out.
>>
>>> +            3. Only svadu in DT: use svadu.
>> Again, statement of the obvious?
>>
>>> +            4. Both svade and svadu in DT: default to svade (Linux can switch to
>>> +               svadu once the SBI FWFT extension is available).
>> Same here as in the Svade entry.
>>
>> Thanks,
>> Conor.
>>
> Regards,
> Anup
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2024-06-21  8:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240605121512.32083-1-yongxuan.wang@sifive.com>
2024-06-05 12:15 ` [PATCH v5 2/4] dt-bindings: riscv: Add Svade and Svadu Entries Yong-Xuan Wang
2024-06-05 16:54   ` Conor Dooley
2024-06-18 10:38     ` Yong-Xuan Wang
2024-06-19 18:11       ` Conor Dooley
2024-06-20  6:25     ` Anup Patel
2024-06-21  8:33       ` Andrew Jones
2024-06-21 10:11         ` Conor Dooley
2024-06-25 10:15         ` Yong-Xuan Wang
2024-06-21  8:37       ` Alexandre Ghiti [this message]
2024-06-21 10:17         ` Conor Dooley
2024-06-21 12:42           ` Alexandre Ghiti
2024-06-21 13:15             ` Andrew Jones
2024-06-21 14:04               ` Conor Dooley
2024-06-21 14:52                 ` Andrew Jones
2024-06-21 14:58                   ` Conor Dooley
2024-06-21 15:08                     ` Andrew Jones
2024-06-22 12:01                       ` Conor Dooley
2024-06-25 10:17                         ` Yong-Xuan Wang
2024-06-25 10:19                         ` Andrew Jones
2024-06-21  7:56   ` Alexandre Ghiti

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=40a7d568-3855-48fb-a73c-339e1790f12f@ghiti.fr \
    --to=alex@ghiti.fr \
    --cc=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=apatel@ventanamicro.com \
    --cc=conor@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=greentime.hu@sifive.com \
    --cc=krzk+dt@kernel.org \
    --cc=kvm-riscv@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh@kernel.org \
    --cc=vincent.chen@sifive.com \
    --cc=yongxuan.wang@sifive.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 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).