lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <402C3422-0248-4C0F-991E-C0C4BBB0FA72@jrtc27.com>
Date: Sat, 29 Jun 2024 14:09:34 +0100
From: Jessica Clarke <jrtc27@...c27.com>
To: Conor Dooley <conor@...nel.org>
Cc: Yong-Xuan Wang <yongxuan.wang@...ive.com>,
 LKML <linux-kernel@...r.kernel.org>,
 linux-riscv <linux-riscv@...ts.infradead.org>,
 kvm-riscv@...ts.infradead.org,
 kvm@...r.kernel.org,
 Greentime Hu <greentime.hu@...ive.com>,
 Vincent Chen <vincent.chen@...ive.com>,
 Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>,
 Albert Ou <aou@...s.berkeley.edu>,
 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v6 2/4] dt-bindings: riscv: Add Svade and Svadu Entries

On 28 Jun 2024, at 17:19, Conor Dooley <conor@...nel.org> wrote:
> 
> On Fri, Jun 28, 2024 at 05:37:06PM +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@...ive.com>
>> ---
>> .../devicetree/bindings/riscv/extensions.yaml | 28 +++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
>> index 468c646247aa..c3d053ce7783 100644
>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
>> @@ -153,6 +153,34 @@ 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 SW-managed PTE A/D
>> +            bit updates 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 present in DT =>
> 
>>                It is technically
>> +               unknown whether the platform uses Svade or Svadu. Supervisor may
>> +               assume Svade to be present and enabled or it can discover based
>> +               on mvendorid, marchid, and mimpid.
> 
> I would just write "for backwards compatibility, if neither Svade nor
> Svadu appear in the devicetree the supervisor may assume Svade to be
> present and enabled". If there are systems that this behaviour causes
> problems for, we can deal with them iff they appear. I don't think
> looking at m*id would be sufficient here anyway, since the firmware can
> have an impact. I'd just drop that part entirely.

Older QEMU falls into that category, as do Bluespec’s soft-cores (which
ours are derived from at Cambridge). I feel that, in reality, one
should be prepared to handle both trapping and atomic updates if
writing an OS that aims to support case 1.

Jess


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ