Topics

[RISC-V] [tech-config] Discovery mechanism for Zfinx


Tariq Kurd
 

(I change TECH-TEE to TECH-UNPRIV on CC)

 

Yes – very interesting.

We can detect Zfinx by checking that

 

Misa.F is read-only 0

Mstatus.FS is read-only 0

Accesses to FCSR don’t trap.

 

And I agree there’s no reason to enable/disable Z[FD]inx, because you’re not going to save context switch time.

 

So – I agree – allocating read-only FCSR bits for

 

ZFinx, ZDinx, ZQinx, Zfinx_Zfh make sense

 

But we also need bits for any parts of V which use FP for the Zfinx version

 

It might be worth allocating a new CSR for this – currently there are 24 bits available, that should be enough to keep us going for a while but who knows…..

 

It might be prudent to allocate a new one: misa_zfinx or something like that (and also the presence of that would indicate Zfinx in generate so we wouldn’t need a bit to indicate the ZFinx verson of F which must always be present.

 

What do people think?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 23 February 2021 20:28
To: tech-config@...
Cc: tech-tee <tech-tee@...>; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

Z[fd]inx cannot be enabled or disabled; it's either it's in or it's out - at least, that was the way it was when combined with F & D.

So you could enable F & D, but not Zfinx separately.

If we separate them, then misa.F/D would be hardwired to zero if Z[fd]inx is present, and vice-versa. Legal combinations are thus

  F                            or nothing

  F,        FD              or nothing

  Zfinx                      or nothing

  Zfinx, Zfinx_Zdinx, or nothing

 

off topic: 

I'm not quite sure what the point of making misa.F/D be writable myself, since xstatus.fs==0 has the same effect - with 1 difference: 

   if misa.F/D are zero, then you can't count on getting an illegal op trap when executing FP ops, but setting xstatus.fs==0 will.

The benefits of allowing misa.F/D to be writable are (IMHO) minor or a bit far-fetched:

 - you save a little bit illegal opcode detection 

 - it enables switching in a custom extension in place of F/D

 

This is moot in the case of Z[f/d]inx, since .FS must be rdonly 0.  

But, the spec says:

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

This must be changed in the spec, so you need to make that explicit in the priv spec.

 

It isn't clear to me whether accesses to fcsr must trap if no FP extension is present.

If it does, then you can detect whether Z[f/d]inx is present if 

     misa.F/D are read-only 0, 

     mstatus.FS is read-only 0, and 

     accesses to fcsr don't trap.

It doesn't help to set if they are enabled or not. One option is to just not allow disabling them.

It also doesn't help to determine if Zdinx is present, because you can't depend on trapping D-extension ops.

For that, a (couple of) read-only fcsr bits is the easy choice.

 

 

On Tue, Feb 23, 2021 at 9:00 AM Greg Favor <gfavor@...> wrote:

On Tue, Feb 23, 2021 at 12:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

I’ve made a big update to the Zfinx spec to separate out extensions, so instead of [FDQ]+Zfinx we now have Z[FDQ]inx, so it’s no longer a modification of [FDQ] but an actual set of new extensions which conflict with [FDQ].

 

Previously I was using misa.[FDQ] for discovery, but now I can’t.

 

Note that the misa CSR is not just for discovery, but also for enabling/disabling an extension.  Also note that the arch spec has ideas like this: "If an ISA feature x depends on an ISA feature y, then attempting to enable feature x but disable feature y results in both features being disabled. For example, setting “F”=0 and “D”=1 results in both “F” and “D” being cleared."  In this case, it seems like a Z[FDQ]inx extension being enabled should disable the corresponding Z[FDQ] extension and whatever knock-on feature disables.

 

The obvious question is then where (in a CSR presumably) is enable/disable of each of the Z*inx extensions provided?  If there is going to be a growing set of Z*inx extensions (as the text below suggests), then maybe there should be a separate CSR just for Z*inx extensions?  (This CSR would also then provide the answer to the above discovery question at a hardware level.)

 

Greg

 

What’s the correct discovery mechanism for Z[FDQ]inx? And I need Zfinx_Zfh as well, ZfinxV for vector, and to be able to allocate a Zfinx version of any future FP extension.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 


Allen Baum
 

Detecting that F and D and mstatus.FS are read-only zero and fcsr is accessible is not enough; 
I think Andrew gently reminded me there could be a future or custom extension that uses fcsr, so that is a false positive.

My preference would be to enable discovery through the configuration structure proposal, if you can wait. 

The reason for enable/disable would be if someone wanted to use those opcodes for a custom extension, and be able to switch it in or out.
Not something I would endorse, myself.... but you'd probably require an m-mode CSR for that. I'd be plenty happy if the spec didn't allow that.

I would let V specify  what it needed, but coordinate with them. I would find it rather unusual that someone would have Zfinx and Vector.
That combination doesn't make a lot of sense to me; Zfinx basically just saves the FPRegister file, and if you have V you'll already be paying a lot more than that.


On Wed, Feb 24, 2021 at 1:50 AM Tariq Kurd <tariq.kurd@...> wrote:

(I change TECH-TEE to TECH-UNPRIV on CC)

 

Yes – very interesting.

We can detect Zfinx by checking that

 

Misa.F is read-only 0

Mstatus.FS is read-only 0

Accesses to FCSR don’t trap.

 

And I agree there’s no reason to enable/disable Z[FD]inx, because you’re not going to save context switch time.

 

So – I agree – allocating read-only FCSR bits for

 

ZFinx, ZDinx, ZQinx, Zfinx_Zfh make sense

 

But we also need bits for any parts of V which use FP for the Zfinx version

 

It might be worth allocating a new CSR for this – currently there are 24 bits available, that should be enough to keep us going for a while but who knows…..

 

It might be prudent to allocate a new one: misa_zfinx or something like that (and also the presence of that would indicate Zfinx in generate so we wouldn’t need a bit to indicate the ZFinx verson of F which must always be present.

 

What do people think?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 23 February 2021 20:28
To: tech-config@...
Cc: tech-tee <tech-tee@...>; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

Z[fd]inx cannot be enabled or disabled; it's either it's in or it's out - at least, that was the way it was when combined with F & D.

So you could enable F & D, but not Zfinx separately.

If we separate them, then misa.F/D would be hardwired to zero if Z[fd]inx is present, and vice-versa. Legal combinations are thus

  F                            or nothing

  F,        FD              or nothing

  Zfinx                      or nothing

  Zfinx, Zfinx_Zdinx, or nothing

 

off topic: 

I'm not quite sure what the point of making misa.F/D be writable myself, since xstatus.fs==0 has the same effect - with 1 difference: 

   if misa.F/D are zero, then you can't count on getting an illegal op trap when executing FP ops, but setting xstatus.fs==0 will.

The benefits of allowing misa.F/D to be writable are (IMHO) minor or a bit far-fetched:

 - you save a little bit illegal opcode detection 

 - it enables switching in a custom extension in place of F/D

 

This is moot in the case of Z[f/d]inx, since .FS must be rdonly 0.  

But, the spec says:

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

This must be changed in the spec, so you need to make that explicit in the priv spec.

 

It isn't clear to me whether accesses to fcsr must trap if no FP extension is present.

If it does, then you can detect whether Z[f/d]inx is present if 

     misa.F/D are read-only 0, 

     mstatus.FS is read-only 0, and 

     accesses to fcsr don't trap.

It doesn't help to set if they are enabled or not. One option is to just not allow disabling them.

It also doesn't help to determine if Zdinx is present, because you can't depend on trapping D-extension ops.

For that, a (couple of) read-only fcsr bits is the easy choice.

 

 

On Tue, Feb 23, 2021 at 9:00 AM Greg Favor <gfavor@...> wrote:

On Tue, Feb 23, 2021 at 12:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

I’ve made a big update to the Zfinx spec to separate out extensions, so instead of [FDQ]+Zfinx we now have Z[FDQ]inx, so it’s no longer a modification of [FDQ] but an actual set of new extensions which conflict with [FDQ].

 

Previously I was using misa.[FDQ] for discovery, but now I can’t.

 

Note that the misa CSR is not just for discovery, but also for enabling/disabling an extension.  Also note that the arch spec has ideas like this: "If an ISA feature x depends on an ISA feature y, then attempting to enable feature x but disable feature y results in both features being disabled. For example, setting “F”=0 and “D”=1 results in both “F” and “D” being cleared."  In this case, it seems like a Z[FDQ]inx extension being enabled should disable the corresponding Z[FDQ] extension and whatever knock-on feature disables.

 

The obvious question is then where (in a CSR presumably) is enable/disable of each of the Z*inx extensions provided?  If there is going to be a growing set of Z*inx extensions (as the text below suggests), then maybe there should be a separate CSR just for Z*inx extensions?  (This CSR would also then provide the answer to the above discovery question at a hardware level.)

 

Greg

 

What’s the correct discovery mechanism for Z[FDQ]inx? And I need Zfinx_Zfh as well, ZfinxV for vector, and to be able to allocate a Zfinx version of any future FP extension.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 


Greg Favor
 

Doesn't this reasoning (that no enable/disable is needed for Zfinx) also apply to not needing enable/disable for F and D - which do in fact exist?  Or, put differently, why does whatever reason for F and D possibly being enable/disable-able, not also apply to Zfinx?

Btw, no Zfinx enable/disable means that a virtualized scenario - where the underlying hardware supports running both VMs that use FD and VMs that instead use Zfinx - would not be possible.  (Today, analogously, a hypervisor could run a mixture of VMs that use and don't use hardware FP support.)  But I also acknowledge that maybe Zfinx doesn't need to worry about and support such a virtualization scenario.

Greg


On Wed, Feb 24, 2021 at 10:10 AM Allen Baum <allen.baum@...> wrote:
Detecting that F and D and mstatus.FS are read-only zero and fcsr is accessible is not enough; 
I think Andrew gently reminded me there could be a future or custom extension that uses fcsr, so that is a false positive.

My preference would be to enable discovery through the configuration structure proposal, if you can wait. 

The reason for enable/disable would be if someone wanted to use those opcodes for a custom extension, and be able to switch it in or out.
Not something I would endorse, myself.... but you'd probably require an m-mode CSR for that. I'd be plenty happy if the spec didn't allow that.

I would let V specify  what it needed, but coordinate with them. I would find it rather unusual that someone would have Zfinx and Vector.
That combination doesn't make a lot of sense to me; Zfinx basically just saves the FPRegister file, and if you have V you'll already be paying a lot more than that.


On Wed, Feb 24, 2021 at 1:50 AM Tariq Kurd <tariq.kurd@...> wrote:

(I change TECH-TEE to TECH-UNPRIV on CC)

 

Yes – very interesting.

We can detect Zfinx by checking that

 

Misa.F is read-only 0

Mstatus.FS is read-only 0

Accesses to FCSR don’t trap.

 

And I agree there’s no reason to enable/disable Z[FD]inx, because you’re not going to save context switch time.

 

So – I agree – allocating read-only FCSR bits for

 

ZFinx, ZDinx, ZQinx, Zfinx_Zfh make sense

 

But we also need bits for any parts of V which use FP for the Zfinx version

 

It might be worth allocating a new CSR for this – currently there are 24 bits available, that should be enough to keep us going for a while but who knows…..

 

It might be prudent to allocate a new one: misa_zfinx or something like that (and also the presence of that would indicate Zfinx in generate so we wouldn’t need a bit to indicate the ZFinx verson of F which must always be present.

 

What do people think?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 23 February 2021 20:28
To: tech-config@...
Cc: tech-tee <tech-tee@...>; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

Z[fd]inx cannot be enabled or disabled; it's either it's in or it's out - at least, that was the way it was when combined with F & D.

So you could enable F & D, but not Zfinx separately.

If we separate them, then misa.F/D would be hardwired to zero if Z[fd]inx is present, and vice-versa. Legal combinations are thus

  F                            or nothing

  F,        FD              or nothing

  Zfinx                      or nothing

  Zfinx, Zfinx_Zdinx, or nothing

 

off topic: 

I'm not quite sure what the point of making misa.F/D be writable myself, since xstatus.fs==0 has the same effect - with 1 difference: 

   if misa.F/D are zero, then you can't count on getting an illegal op trap when executing FP ops, but setting xstatus.fs==0 will.

The benefits of allowing misa.F/D to be writable are (IMHO) minor or a bit far-fetched:

 - you save a little bit illegal opcode detection 

 - it enables switching in a custom extension in place of F/D

 

This is moot in the case of Z[f/d]inx, since .FS must be rdonly 0.  

But, the spec says:

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

This must be changed in the spec, so you need to make that explicit in the priv spec.

 

It isn't clear to me whether accesses to fcsr must trap if no FP extension is present.

If it does, then you can detect whether Z[f/d]inx is present if 

     misa.F/D are read-only 0, 

     mstatus.FS is read-only 0, and 

     accesses to fcsr don't trap.

It doesn't help to set if they are enabled or not. One option is to just not allow disabling them.

It also doesn't help to determine if Zdinx is present, because you can't depend on trapping D-extension ops.

For that, a (couple of) read-only fcsr bits is the easy choice.

 

 

On Tue, Feb 23, 2021 at 9:00 AM Greg Favor <gfavor@...> wrote:

On Tue, Feb 23, 2021 at 12:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

I’ve made a big update to the Zfinx spec to separate out extensions, so instead of [FDQ]+Zfinx we now have Z[FDQ]inx, so it’s no longer a modification of [FDQ] but an actual set of new extensions which conflict with [FDQ].

 

Previously I was using misa.[FDQ] for discovery, but now I can’t.

 

Note that the misa CSR is not just for discovery, but also for enabling/disabling an extension.  Also note that the arch spec has ideas like this: "If an ISA feature x depends on an ISA feature y, then attempting to enable feature x but disable feature y results in both features being disabled. For example, setting “F”=0 and “D”=1 results in both “F” and “D” being cleared."  In this case, it seems like a Z[FDQ]inx extension being enabled should disable the corresponding Z[FDQ] extension and whatever knock-on feature disables.

 

The obvious question is then where (in a CSR presumably) is enable/disable of each of the Z*inx extensions provided?  If there is going to be a growing set of Z*inx extensions (as the text below suggests), then maybe there should be a separate CSR just for Z*inx extensions?  (This CSR would also then provide the answer to the above discovery question at a hardware level.)

 

Greg

 

What’s the correct discovery mechanism for Z[FDQ]inx? And I need Zfinx_Zfh as well, ZfinxV for vector, and to be able to allocate a Zfinx version of any future FP extension.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 


Greg Favor
 

On Wed, Feb 24, 2021 at 10:10 AM Allen Baum <allen.baum@...> wrote:
My preference would be to enable discovery through the configuration structure proposal, if you can wait. 

Note that the practice thus far in the architecture is for all optional (and WARL) features to be hardware-discoverable - even though there will eventually also be a universal RISC-V software discovery mechanism that comes along.  I don't think anyone has said that that practice must continue forward with new extensions, but I also haven't heard anyone say that that is alright to drop going forward.  I would suggest getting an Ok on this from Krste and/or Andrew (which I've cc'ed).

Greg

 


mark
 

maybe we are too early for this discussion but I favor not having to do code snippets to see if something traps, etc.

I liked krste's words around eventually having all discovery of extensions and their parameters coming in a uniform way from CSRs.

Mark


On Wed, Feb 24, 2021 at 1:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

(I change TECH-TEE to TECH-UNPRIV on CC)

 

Yes – very interesting.

We can detect Zfinx by checking that

 

Misa.F is read-only 0

Mstatus.FS is read-only 0

Accesses to FCSR don’t trap.

 

And I agree there’s no reason to enable/disable Z[FD]inx, because you’re not going to save context switch time.

 

So – I agree – allocating read-only FCSR bits for

 

ZFinx, ZDinx, ZQinx, Zfinx_Zfh make sense

 

But we also need bits for any parts of V which use FP for the Zfinx version

 

It might be worth allocating a new CSR for this – currently there are 24 bits available, that should be enough to keep us going for a while but who knows…..

 

It might be prudent to allocate a new one: misa_zfinx or something like that (and also the presence of that would indicate Zfinx in generate so we wouldn’t need a bit to indicate the ZFinx verson of F which must always be present.

 

What do people think?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 23 February 2021 20:28
To: tech-config@...
Cc: tech-tee <tech-tee@...>; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

Z[fd]inx cannot be enabled or disabled; it's either it's in or it's out - at least, that was the way it was when combined with F & D.

So you could enable F & D, but not Zfinx separately.

If we separate them, then misa.F/D would be hardwired to zero if Z[fd]inx is present, and vice-versa. Legal combinations are thus

  F                            or nothing

  F,        FD              or nothing

  Zfinx                      or nothing

  Zfinx, Zfinx_Zdinx, or nothing

 

off topic: 

I'm not quite sure what the point of making misa.F/D be writable myself, since xstatus.fs==0 has the same effect - with 1 difference: 

   if misa.F/D are zero, then you can't count on getting an illegal op trap when executing FP ops, but setting xstatus.fs==0 will.

The benefits of allowing misa.F/D to be writable are (IMHO) minor or a bit far-fetched:

 - you save a little bit illegal opcode detection 

 - it enables switching in a custom extension in place of F/D

 

This is moot in the case of Z[f/d]inx, since .FS must be rdonly 0.  

But, the spec says:

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

This must be changed in the spec, so you need to make that explicit in the priv spec.

 

It isn't clear to me whether accesses to fcsr must trap if no FP extension is present.

If it does, then you can detect whether Z[f/d]inx is present if 

     misa.F/D are read-only 0, 

     mstatus.FS is read-only 0, and 

     accesses to fcsr don't trap.

It doesn't help to set if they are enabled or not. One option is to just not allow disabling them.

It also doesn't help to determine if Zdinx is present, because you can't depend on trapping D-extension ops.

For that, a (couple of) read-only fcsr bits is the easy choice.

 

 

On Tue, Feb 23, 2021 at 9:00 AM Greg Favor <gfavor@...> wrote:

On Tue, Feb 23, 2021 at 12:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

I’ve made a big update to the Zfinx spec to separate out extensions, so instead of [FDQ]+Zfinx we now have Z[FDQ]inx, so it’s no longer a modification of [FDQ] but an actual set of new extensions which conflict with [FDQ].

 

Previously I was using misa.[FDQ] for discovery, but now I can’t.

 

Note that the misa CSR is not just for discovery, but also for enabling/disabling an extension.  Also note that the arch spec has ideas like this: "If an ISA feature x depends on an ISA feature y, then attempting to enable feature x but disable feature y results in both features being disabled. For example, setting “F”=0 and “D”=1 results in both “F” and “D” being cleared."  In this case, it seems like a Z[FDQ]inx extension being enabled should disable the corresponding Z[FDQ] extension and whatever knock-on feature disables.

 

The obvious question is then where (in a CSR presumably) is enable/disable of each of the Z*inx extensions provided?  If there is going to be a growing set of Z*inx extensions (as the text below suggests), then maybe there should be a separate CSR just for Z*inx extensions?  (This CSR would also then provide the answer to the above discovery question at a hardware level.)

 

Greg

 

What’s the correct discovery mechanism for Z[FDQ]inx? And I need Zfinx_Zfh as well, ZfinxV for vector, and to be able to allocate a Zfinx version of any future FP extension.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

--
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv


Allen Baum
 

I didn't think I was saying anything different.
There are several approaches to this:
-  per extension CSRs (possibly merged with any other CSRs that an extension already needs)
- common MISA-like CSRs, shared between exteensions, with a bit per extension or sub-extension (we'd need more CSRs, clearly)
- a CSR array, so a CSR with an array index, and another with the array data (backwards compatible if MISA is the data CSR)
- a CSR that points to an MMIO array
.. and probably others.

The question I'm asking is whether we should do anything other than #1 - the conventional choice - right now.

On Wed, Feb 24, 2021 at 11:57 AM Mark Himelstein <markhimelstein@...> wrote:
maybe we are too early for this discussion but I favor not having to do code snippets to see if something traps, etc.

I liked krste's words around eventually having all discovery of extensions and their parameters coming in a uniform way from CSRs.

Mark


On Wed, Feb 24, 2021 at 1:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

(I change TECH-TEE to TECH-UNPRIV on CC)

 

Yes – very interesting.

We can detect Zfinx by checking that

 

Misa.F is read-only 0

Mstatus.FS is read-only 0

Accesses to FCSR don’t trap.

 

And I agree there’s no reason to enable/disable Z[FD]inx, because you’re not going to save context switch time.

 

So – I agree – allocating read-only FCSR bits for

 

ZFinx, ZDinx, ZQinx, Zfinx_Zfh make sense

 

But we also need bits for any parts of V which use FP for the Zfinx version

 

It might be worth allocating a new CSR for this – currently there are 24 bits available, that should be enough to keep us going for a while but who knows…..

 

It might be prudent to allocate a new one: misa_zfinx or something like that (and also the presence of that would indicate Zfinx in generate so we wouldn’t need a bit to indicate the ZFinx verson of F which must always be present.

 

What do people think?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 23 February 2021 20:28
To: tech-config@...
Cc: tech-tee <tech-tee@...>; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

Z[fd]inx cannot be enabled or disabled; it's either it's in or it's out - at least, that was the way it was when combined with F & D.

So you could enable F & D, but not Zfinx separately.

If we separate them, then misa.F/D would be hardwired to zero if Z[fd]inx is present, and vice-versa. Legal combinations are thus

  F                            or nothing

  F,        FD              or nothing

  Zfinx                      or nothing

  Zfinx, Zfinx_Zdinx, or nothing

 

off topic: 

I'm not quite sure what the point of making misa.F/D be writable myself, since xstatus.fs==0 has the same effect - with 1 difference: 

   if misa.F/D are zero, then you can't count on getting an illegal op trap when executing FP ops, but setting xstatus.fs==0 will.

The benefits of allowing misa.F/D to be writable are (IMHO) minor or a bit far-fetched:

 - you save a little bit illegal opcode detection 

 - it enables switching in a custom extension in place of F/D

 

This is moot in the case of Z[f/d]inx, since .FS must be rdonly 0.  

But, the spec says:

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

This must be changed in the spec, so you need to make that explicit in the priv spec.

 

It isn't clear to me whether accesses to fcsr must trap if no FP extension is present.

If it does, then you can detect whether Z[f/d]inx is present if 

     misa.F/D are read-only 0, 

     mstatus.FS is read-only 0, and 

     accesses to fcsr don't trap.

It doesn't help to set if they are enabled or not. One option is to just not allow disabling them.

It also doesn't help to determine if Zdinx is present, because you can't depend on trapping D-extension ops.

For that, a (couple of) read-only fcsr bits is the easy choice.

 

 

On Tue, Feb 23, 2021 at 9:00 AM Greg Favor <gfavor@...> wrote:

On Tue, Feb 23, 2021 at 12:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

I’ve made a big update to the Zfinx spec to separate out extensions, so instead of [FDQ]+Zfinx we now have Z[FDQ]inx, so it’s no longer a modification of [FDQ] but an actual set of new extensions which conflict with [FDQ].

 

Previously I was using misa.[FDQ] for discovery, but now I can’t.

 

Note that the misa CSR is not just for discovery, but also for enabling/disabling an extension.  Also note that the arch spec has ideas like this: "If an ISA feature x depends on an ISA feature y, then attempting to enable feature x but disable feature y results in both features being disabled. For example, setting “F”=0 and “D”=1 results in both “F” and “D” being cleared."  In this case, it seems like a Z[FDQ]inx extension being enabled should disable the corresponding Z[FDQ] extension and whatever knock-on feature disables.

 

The obvious question is then where (in a CSR presumably) is enable/disable of each of the Z*inx extensions provided?  If there is going to be a growing set of Z*inx extensions (as the text below suggests), then maybe there should be a separate CSR just for Z*inx extensions?  (This CSR would also then provide the answer to the above discovery question at a hardware level.)

 

Greg

 

What’s the correct discovery mechanism for Z[FDQ]inx? And I need Zfinx_Zfh as well, ZfinxV for vector, and to be able to allocate a Zfinx version of any future FP extension.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

--
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv


Greg Favor
 

Talking with a few people, there are varying views on this.  But it seems like the rough sentiment is trending towards having some form of standardized simple hardware-based discovery method (e.g. some CSR-based scheme) that applies for all extensions/sub-extensions, and not the painful (to varying degrees) "try it and see if you get an exception" approach, or the "each extension does its own thing" approach.  This is along the lines of what Krste espouses and, it turns out, relates with a couple of issues that Andrew, John, and I recently recognized that were leading us to contemplate something similar (which still needs to be fleshed out a bit).  In any case this seems like a growing issue that is aching for a consistent standard approach across extensions.

Greg

P.S. One example of where things can get interesting:  Say you have an extension that introduces new register/CSR state.  The extension is implemented in hardware and is available to be used, but the hardware is running an older "extension unaware" version of OS that is obviously not going to context switch this state.  That creates the makings of a covert communication channel between processes and/or between VMs.  Not a good thing security-wise.


On Wed, Feb 24, 2021 at 3:03 PM Allen Baum <allen.baum@...> wrote:
I didn't think I was saying anything different.
There are several approaches to this:
-  per extension CSRs (possibly merged with any other CSRs that an extension already needs)
- common MISA-like CSRs, shared between exteensions, with a bit per extension or sub-extension (we'd need more CSRs, clearly)
- a CSR array, so a CSR with an array index, and another with the array data (backwards compatible if MISA is the data CSR)
- a CSR that points to an MMIO array
.. and probably others.

The question I'm asking is whether we should do anything other than #1 - the conventional choice - right now.

On Wed, Feb 24, 2021 at 11:57 AM Mark Himelstein <markhimelstein@...> wrote:
maybe we are too early for this discussion but I favor not having to do code snippets to see if something traps, etc.

I liked krste's words around eventually having all discovery of extensions and their parameters coming in a uniform way from CSRs.

Mark


On Wed, Feb 24, 2021 at 1:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

(I change TECH-TEE to TECH-UNPRIV on CC)

 

Yes – very interesting.

We can detect Zfinx by checking that

 

Misa.F is read-only 0

Mstatus.FS is read-only 0

Accesses to FCSR don’t trap.

 

And I agree there’s no reason to enable/disable Z[FD]inx, because you’re not going to save context switch time.

 

So – I agree – allocating read-only FCSR bits for

 

ZFinx, ZDinx, ZQinx, Zfinx_Zfh make sense

 

But we also need bits for any parts of V which use FP for the Zfinx version

 

It might be worth allocating a new CSR for this – currently there are 24 bits available, that should be enough to keep us going for a while but who knows…..

 

It might be prudent to allocate a new one: misa_zfinx or something like that (and also the presence of that would indicate Zfinx in generate so we wouldn’t need a bit to indicate the ZFinx verson of F which must always be present.

 

What do people think?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 23 February 2021 20:28
To: tech-config@...
Cc: tech-tee <tech-tee@...>; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

Z[fd]inx cannot be enabled or disabled; it's either it's in or it's out - at least, that was the way it was when combined with F & D.

So you could enable F & D, but not Zfinx separately.

If we separate them, then misa.F/D would be hardwired to zero if Z[fd]inx is present, and vice-versa. Legal combinations are thus

  F                            or nothing

  F,        FD              or nothing

  Zfinx                      or nothing

  Zfinx, Zfinx_Zdinx, or nothing

 

off topic: 

I'm not quite sure what the point of making misa.F/D be writable myself, since xstatus.fs==0 has the same effect - with 1 difference: 

   if misa.F/D are zero, then you can't count on getting an illegal op trap when executing FP ops, but setting xstatus.fs==0 will.

The benefits of allowing misa.F/D to be writable are (IMHO) minor or a bit far-fetched:

 - you save a little bit illegal opcode detection 

 - it enables switching in a custom extension in place of F/D

 

This is moot in the case of Z[f/d]inx, since .FS must be rdonly 0.  

But, the spec says:

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

This must be changed in the spec, so you need to make that explicit in the priv spec.

 

It isn't clear to me whether accesses to fcsr must trap if no FP extension is present.

If it does, then you can detect whether Z[f/d]inx is present if 

     misa.F/D are read-only 0, 

     mstatus.FS is read-only 0, and 

     accesses to fcsr don't trap.

It doesn't help to set if they are enabled or not. One option is to just not allow disabling them.

It also doesn't help to determine if Zdinx is present, because you can't depend on trapping D-extension ops.

For that, a (couple of) read-only fcsr bits is the easy choice.

 

 

On Tue, Feb 23, 2021 at 9:00 AM Greg Favor <gfavor@...> wrote:

On Tue, Feb 23, 2021 at 12:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

I’ve made a big update to the Zfinx spec to separate out extensions, so instead of [FDQ]+Zfinx we now have Z[FDQ]inx, so it’s no longer a modification of [FDQ] but an actual set of new extensions which conflict with [FDQ].

 

Previously I was using misa.[FDQ] for discovery, but now I can’t.

 

Note that the misa CSR is not just for discovery, but also for enabling/disabling an extension.  Also note that the arch spec has ideas like this: "If an ISA feature x depends on an ISA feature y, then attempting to enable feature x but disable feature y results in both features being disabled. For example, setting “F”=0 and “D”=1 results in both “F” and “D” being cleared."  In this case, it seems like a Z[FDQ]inx extension being enabled should disable the corresponding Z[FDQ] extension and whatever knock-on feature disables.

 

The obvious question is then where (in a CSR presumably) is enable/disable of each of the Z*inx extensions provided?  If there is going to be a growing set of Z*inx extensions (as the text below suggests), then maybe there should be a separate CSR just for Z*inx extensions?  (This CSR would also then provide the answer to the above discovery question at a hardware level.)

 

Greg

 

What’s the correct discovery mechanism for Z[FDQ]inx? And I need Zfinx_Zfh as well, ZfinxV for vector, and to be able to allocate a Zfinx version of any future FP extension.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

--
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv


Greg Favor
 

And to be clear, anything like this would not remove the need for what tech-config is developing.  There also needs to be a good software discovery method that covers and includes a lot more than just whether an extension is implemented (e.g. that extension may have various parameters, WARL things, options, etc.)

Greg


On Wed, Feb 24, 2021 at 7:16 PM Greg Favor <gfavor@...> wrote:
Talking with a few people, there are varying views on this.  But it seems like the rough sentiment is trending towards having some form of standardized simple hardware-based discovery method (e.g. some CSR-based scheme) that applies for all extensions/sub-extensions, and not the painful (to varying degrees) "try it and see if you get an exception" approach, or the "each extension does its own thing" approach.  This is along the lines of what Krste espouses and, it turns out, relates with a couple of issues that Andrew, John, and I recently recognized that were leading us to contemplate something similar (which still needs to be fleshed out a bit).  In any case this seems like a growing issue that is aching for a consistent standard approach across extensions.

Greg

P.S. One example of where things can get interesting:  Say you have an extension that introduces new register/CSR state.  The extension is implemented in hardware and is available to be used, but the hardware is running an older "extension unaware" version of OS that is obviously not going to context switch this state.  That creates the makings of a covert communication channel between processes and/or between VMs.  Not a good thing security-wise.


On Wed, Feb 24, 2021 at 3:03 PM Allen Baum <allen.baum@...> wrote:
I didn't think I was saying anything different.
There are several approaches to this:
-  per extension CSRs (possibly merged with any other CSRs that an extension already needs)
- common MISA-like CSRs, shared between exteensions, with a bit per extension or sub-extension (we'd need more CSRs, clearly)
- a CSR array, so a CSR with an array index, and another with the array data (backwards compatible if MISA is the data CSR)
- a CSR that points to an MMIO array
.. and probably others.

The question I'm asking is whether we should do anything other than #1 - the conventional choice - right now.

On Wed, Feb 24, 2021 at 11:57 AM Mark Himelstein <markhimelstein@...> wrote:
maybe we are too early for this discussion but I favor not having to do code snippets to see if something traps, etc.

I liked krste's words around eventually having all discovery of extensions and their parameters coming in a uniform way from CSRs.

Mark


On Wed, Feb 24, 2021 at 1:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

(I change TECH-TEE to TECH-UNPRIV on CC)

 

Yes – very interesting.

We can detect Zfinx by checking that

 

Misa.F is read-only 0

Mstatus.FS is read-only 0

Accesses to FCSR don’t trap.

 

And I agree there’s no reason to enable/disable Z[FD]inx, because you’re not going to save context switch time.

 

So – I agree – allocating read-only FCSR bits for

 

ZFinx, ZDinx, ZQinx, Zfinx_Zfh make sense

 

But we also need bits for any parts of V which use FP for the Zfinx version

 

It might be worth allocating a new CSR for this – currently there are 24 bits available, that should be enough to keep us going for a while but who knows…..

 

It might be prudent to allocate a new one: misa_zfinx or something like that (and also the presence of that would indicate Zfinx in generate so we wouldn’t need a bit to indicate the ZFinx verson of F which must always be present.

 

What do people think?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 23 February 2021 20:28
To: tech-config@...
Cc: tech-tee <tech-tee@...>; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

Z[fd]inx cannot be enabled or disabled; it's either it's in or it's out - at least, that was the way it was when combined with F & D.

So you could enable F & D, but not Zfinx separately.

If we separate them, then misa.F/D would be hardwired to zero if Z[fd]inx is present, and vice-versa. Legal combinations are thus

  F                            or nothing

  F,        FD              or nothing

  Zfinx                      or nothing

  Zfinx, Zfinx_Zdinx, or nothing

 

off topic: 

I'm not quite sure what the point of making misa.F/D be writable myself, since xstatus.fs==0 has the same effect - with 1 difference: 

   if misa.F/D are zero, then you can't count on getting an illegal op trap when executing FP ops, but setting xstatus.fs==0 will.

The benefits of allowing misa.F/D to be writable are (IMHO) minor or a bit far-fetched:

 - you save a little bit illegal opcode detection 

 - it enables switching in a custom extension in place of F/D

 

This is moot in the case of Z[f/d]inx, since .FS must be rdonly 0.  

But, the spec says:

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

This must be changed in the spec, so you need to make that explicit in the priv spec.

 

It isn't clear to me whether accesses to fcsr must trap if no FP extension is present.

If it does, then you can detect whether Z[f/d]inx is present if 

     misa.F/D are read-only 0, 

     mstatus.FS is read-only 0, and 

     accesses to fcsr don't trap.

It doesn't help to set if they are enabled or not. One option is to just not allow disabling them.

It also doesn't help to determine if Zdinx is present, because you can't depend on trapping D-extension ops.

For that, a (couple of) read-only fcsr bits is the easy choice.

 

 

On Tue, Feb 23, 2021 at 9:00 AM Greg Favor <gfavor@...> wrote:

On Tue, Feb 23, 2021 at 12:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

I’ve made a big update to the Zfinx spec to separate out extensions, so instead of [FDQ]+Zfinx we now have Z[FDQ]inx, so it’s no longer a modification of [FDQ] but an actual set of new extensions which conflict with [FDQ].

 

Previously I was using misa.[FDQ] for discovery, but now I can’t.

 

Note that the misa CSR is not just for discovery, but also for enabling/disabling an extension.  Also note that the arch spec has ideas like this: "If an ISA feature x depends on an ISA feature y, then attempting to enable feature x but disable feature y results in both features being disabled. For example, setting “F”=0 and “D”=1 results in both “F” and “D” being cleared."  In this case, it seems like a Z[FDQ]inx extension being enabled should disable the corresponding Z[FDQ] extension and whatever knock-on feature disables.

 

The obvious question is then where (in a CSR presumably) is enable/disable of each of the Z*inx extensions provided?  If there is going to be a growing set of Z*inx extensions (as the text below suggests), then maybe there should be a separate CSR just for Z*inx extensions?  (This CSR would also then provide the answer to the above discovery question at a hardware level.)

 

Greg

 

What’s the correct discovery mechanism for Z[FDQ]inx? And I need Zfinx_Zfh as well, ZfinxV for vector, and to be able to allocate a Zfinx version of any future FP extension.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

--
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv


Allen Baum
 

If there is state that can be modified, then if it is modified, the mstatus.xs field must be updated.
The platform profile should say that extension is incompatible because it doesn't know how to save and restore the state, right?


On Wed, Feb 24, 2021 at 7:16 PM Greg Favor <gfavor@...> wrote:
Talking with a few people, there are varying views on this.  But it seems like the rough sentiment is trending towards having some form of standardized simple hardware-based discovery method (e.g. some CSR-based scheme) that applies for all extensions/sub-extensions, and not the painful (to varying degrees) "try it and see if you get an exception" approach, or the "each extension does its own thing" approach.  This is along the lines of what Krste espouses and, it turns out, relates with a couple of issues that Andrew, John, and I recently recognized that were leading us to contemplate something similar (which still needs to be fleshed out a bit).  In any case this seems like a growing issue that is aching for a consistent standard approach across extensions.

Greg

P.S. One example of where things can get interesting:  Say you have an extension that introduces new register/CSR state.  The extension is implemented in hardware and is available to be used, but the hardware is running an older "extension unaware" version of OS that is obviously not going to context switch this state.  That creates the makings of a covert communication channel between processes and/or between VMs.  Not a good thing security-wise.


On Wed, Feb 24, 2021 at 3:03 PM Allen Baum <allen.baum@...> wrote:
I didn't think I was saying anything different.
There are several approaches to this:
-  per extension CSRs (possibly merged with any other CSRs that an extension already needs)
- common MISA-like CSRs, shared between exteensions, with a bit per extension or sub-extension (we'd need more CSRs, clearly)
- a CSR array, so a CSR with an array index, and another with the array data (backwards compatible if MISA is the data CSR)
- a CSR that points to an MMIO array
.. and probably others.

The question I'm asking is whether we should do anything other than #1 - the conventional choice - right now.

On Wed, Feb 24, 2021 at 11:57 AM Mark Himelstein <markhimelstein@...> wrote:
maybe we are too early for this discussion but I favor not having to do code snippets to see if something traps, etc.

I liked krste's words around eventually having all discovery of extensions and their parameters coming in a uniform way from CSRs.

Mark


On Wed, Feb 24, 2021 at 1:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

(I change TECH-TEE to TECH-UNPRIV on CC)

 

Yes – very interesting.

We can detect Zfinx by checking that

 

Misa.F is read-only 0

Mstatus.FS is read-only 0

Accesses to FCSR don’t trap.

 

And I agree there’s no reason to enable/disable Z[FD]inx, because you’re not going to save context switch time.

 

So – I agree – allocating read-only FCSR bits for

 

ZFinx, ZDinx, ZQinx, Zfinx_Zfh make sense

 

But we also need bits for any parts of V which use FP for the Zfinx version

 

It might be worth allocating a new CSR for this – currently there are 24 bits available, that should be enough to keep us going for a while but who knows…..

 

It might be prudent to allocate a new one: misa_zfinx or something like that (and also the presence of that would indicate Zfinx in generate so we wouldn’t need a bit to indicate the ZFinx verson of F which must always be present.

 

What do people think?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 23 February 2021 20:28
To: tech-config@...
Cc: tech-tee <tech-tee@...>; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

Z[fd]inx cannot be enabled or disabled; it's either it's in or it's out - at least, that was the way it was when combined with F & D.

So you could enable F & D, but not Zfinx separately.

If we separate them, then misa.F/D would be hardwired to zero if Z[fd]inx is present, and vice-versa. Legal combinations are thus

  F                            or nothing

  F,        FD              or nothing

  Zfinx                      or nothing

  Zfinx, Zfinx_Zdinx, or nothing

 

off topic: 

I'm not quite sure what the point of making misa.F/D be writable myself, since xstatus.fs==0 has the same effect - with 1 difference: 

   if misa.F/D are zero, then you can't count on getting an illegal op trap when executing FP ops, but setting xstatus.fs==0 will.

The benefits of allowing misa.F/D to be writable are (IMHO) minor or a bit far-fetched:

 - you save a little bit illegal opcode detection 

 - it enables switching in a custom extension in place of F/D

 

This is moot in the case of Z[f/d]inx, since .FS must be rdonly 0.  

But, the spec says:

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

This must be changed in the spec, so you need to make that explicit in the priv spec.

 

It isn't clear to me whether accesses to fcsr must trap if no FP extension is present.

If it does, then you can detect whether Z[f/d]inx is present if 

     misa.F/D are read-only 0, 

     mstatus.FS is read-only 0, and 

     accesses to fcsr don't trap.

It doesn't help to set if they are enabled or not. One option is to just not allow disabling them.

It also doesn't help to determine if Zdinx is present, because you can't depend on trapping D-extension ops.

For that, a (couple of) read-only fcsr bits is the easy choice.

 

 

On Tue, Feb 23, 2021 at 9:00 AM Greg Favor <gfavor@...> wrote:

On Tue, Feb 23, 2021 at 12:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

I’ve made a big update to the Zfinx spec to separate out extensions, so instead of [FDQ]+Zfinx we now have Z[FDQ]inx, so it’s no longer a modification of [FDQ] but an actual set of new extensions which conflict with [FDQ].

 

Previously I was using misa.[FDQ] for discovery, but now I can’t.

 

Note that the misa CSR is not just for discovery, but also for enabling/disabling an extension.  Also note that the arch spec has ideas like this: "If an ISA feature x depends on an ISA feature y, then attempting to enable feature x but disable feature y results in both features being disabled. For example, setting “F”=0 and “D”=1 results in both “F” and “D” being cleared."  In this case, it seems like a Z[FDQ]inx extension being enabled should disable the corresponding Z[FDQ] extension and whatever knock-on feature disables.

 

The obvious question is then where (in a CSR presumably) is enable/disable of each of the Z*inx extensions provided?  If there is going to be a growing set of Z*inx extensions (as the text below suggests), then maybe there should be a separate CSR just for Z*inx extensions?  (This CSR would also then provide the answer to the above discovery question at a hardware level.)

 

Greg

 

What’s the correct discovery mechanism for Z[FDQ]inx? And I need Zfinx_Zfh as well, ZfinxV for vector, and to be able to allocate a Zfinx version of any future FP extension.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

--
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv


Greg Favor
 

On Wed, Feb 24, 2021 at 11:11 PM Allen Baum <allen.baum@...> wrote:
If there is state that can be modified, then if it is modified, the mstatus.xs field must be updated.

Yes, but the OS still won't be aware of the extra state and won't know what code to use to save/restore that state.  It will only know about the state covered by XS that it knows about (and won't have any idea that this unknown extension caused the mstatus.XS state change).  And it won't know about there being another field in one of that extension's CSRs that encodes that extension's equivalent of the XS states (as the Priv spec requires an extension to provide).
 
The platform profile should say that extension is incompatible because it doesn't know how to save and restore the state, right?

But a hardware implementation that is compatible with platform X will likely also support running software compatible with platform X-1 (i.e. the hardware can run old versions of software).

Greg


mark
 

Thank you Greg.

As discussed, I suggest we get this in place quickly so all new extensions can use it.

Also I suggest we document the whole discovery story in one place. So if enable (and by association discovery) is CSR but parameters are config and if could differ between RVA and RVM, I suggest we put all of it together in one chapter or appendix (or elsewhere) so readers don't have to piece it together by looking in lots of places. Is this possible?

thanks
Mark


On Wed, Feb 24, 2021 at 7:20 PM Greg Favor <gfavor@...> wrote:
And to be clear, anything like this would not remove the need for what tech-config is developing.  There also needs to be a good software discovery method that covers and includes a lot more than just whether an extension is implemented (e.g. that extension may have various parameters, WARL things, options, etc.)

Greg


On Wed, Feb 24, 2021 at 7:16 PM Greg Favor <gfavor@...> wrote:
Talking with a few people, there are varying views on this.  But it seems like the rough sentiment is trending towards having some form of standardized simple hardware-based discovery method (e.g. some CSR-based scheme) that applies for all extensions/sub-extensions, and not the painful (to varying degrees) "try it and see if you get an exception" approach, or the "each extension does its own thing" approach.  This is along the lines of what Krste espouses and, it turns out, relates with a couple of issues that Andrew, John, and I recently recognized that were leading us to contemplate something similar (which still needs to be fleshed out a bit).  In any case this seems like a growing issue that is aching for a consistent standard approach across extensions.

Greg

P.S. One example of where things can get interesting:  Say you have an extension that introduces new register/CSR state.  The extension is implemented in hardware and is available to be used, but the hardware is running an older "extension unaware" version of OS that is obviously not going to context switch this state.  That creates the makings of a covert communication channel between processes and/or between VMs.  Not a good thing security-wise.


On Wed, Feb 24, 2021 at 3:03 PM Allen Baum <allen.baum@...> wrote:
I didn't think I was saying anything different.
There are several approaches to this:
-  per extension CSRs (possibly merged with any other CSRs that an extension already needs)
- common MISA-like CSRs, shared between exteensions, with a bit per extension or sub-extension (we'd need more CSRs, clearly)
- a CSR array, so a CSR with an array index, and another with the array data (backwards compatible if MISA is the data CSR)
- a CSR that points to an MMIO array
.. and probably others.

The question I'm asking is whether we should do anything other than #1 - the conventional choice - right now.

On Wed, Feb 24, 2021 at 11:57 AM Mark Himelstein <markhimelstein@...> wrote:
maybe we are too early for this discussion but I favor not having to do code snippets to see if something traps, etc.

I liked krste's words around eventually having all discovery of extensions and their parameters coming in a uniform way from CSRs.

Mark


On Wed, Feb 24, 2021 at 1:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

(I change TECH-TEE to TECH-UNPRIV on CC)

 

Yes – very interesting.

We can detect Zfinx by checking that

 

Misa.F is read-only 0

Mstatus.FS is read-only 0

Accesses to FCSR don’t trap.

 

And I agree there’s no reason to enable/disable Z[FD]inx, because you’re not going to save context switch time.

 

So – I agree – allocating read-only FCSR bits for

 

ZFinx, ZDinx, ZQinx, Zfinx_Zfh make sense

 

But we also need bits for any parts of V which use FP for the Zfinx version

 

It might be worth allocating a new CSR for this – currently there are 24 bits available, that should be enough to keep us going for a while but who knows…..

 

It might be prudent to allocate a new one: misa_zfinx or something like that (and also the presence of that would indicate Zfinx in generate so we wouldn’t need a bit to indicate the ZFinx verson of F which must always be present.

 

What do people think?

 

Tariq

 

From: Allen Baum [mailto:allen.baum@...]
Sent: 23 February 2021 20:28
To: tech-config@...
Cc: tech-tee <tech-tee@...>; Tariq Kurd <tariq.kurd@...>
Subject: Re: [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

Z[fd]inx cannot be enabled or disabled; it's either it's in or it's out - at least, that was the way it was when combined with F & D.

So you could enable F & D, but not Zfinx separately.

If we separate them, then misa.F/D would be hardwired to zero if Z[fd]inx is present, and vice-versa. Legal combinations are thus

  F                            or nothing

  F,        FD              or nothing

  Zfinx                      or nothing

  Zfinx, Zfinx_Zdinx, or nothing

 

off topic: 

I'm not quite sure what the point of making misa.F/D be writable myself, since xstatus.fs==0 has the same effect - with 1 difference: 

   if misa.F/D are zero, then you can't count on getting an illegal op trap when executing FP ops, but setting xstatus.fs==0 will.

The benefits of allowing misa.F/D to be writable are (IMHO) minor or a bit far-fetched:

 - you save a little bit illegal opcode detection 

 - it enables switching in a custom extension in place of F/D

 

This is moot in the case of Z[f/d]inx, since .FS must be rdonly 0.  

But, the spec says:

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

This must be changed in the spec, so you need to make that explicit in the priv spec.

 

It isn't clear to me whether accesses to fcsr must trap if no FP extension is present.

If it does, then you can detect whether Z[f/d]inx is present if 

     misa.F/D are read-only 0, 

     mstatus.FS is read-only 0, and 

     accesses to fcsr don't trap.

It doesn't help to set if they are enabled or not. One option is to just not allow disabling them.

It also doesn't help to determine if Zdinx is present, because you can't depend on trapping D-extension ops.

For that, a (couple of) read-only fcsr bits is the easy choice.

 

 

On Tue, Feb 23, 2021 at 9:00 AM Greg Favor <gfavor@...> wrote:

On Tue, Feb 23, 2021 at 12:50 AM Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> wrote:

https://github.com/riscv/riscv-zfinx/blob/master/Zfinx_spec.adoc

I’ve made a big update to the Zfinx spec to separate out extensions, so instead of [FDQ]+Zfinx we now have Z[FDQ]inx, so it’s no longer a modification of [FDQ] but an actual set of new extensions which conflict with [FDQ].

 

Previously I was using misa.[FDQ] for discovery, but now I can’t.

 

Note that the misa CSR is not just for discovery, but also for enabling/disabling an extension.  Also note that the arch spec has ideas like this: "If an ISA feature x depends on an ISA feature y, then attempting to enable feature x but disable feature y results in both features being disabled. For example, setting “F”=0 and “D”=1 results in both “F” and “D” being cleared."  In this case, it seems like a Z[FDQ]inx extension being enabled should disable the corresponding Z[FDQ] extension and whatever knock-on feature disables.

 

The obvious question is then where (in a CSR presumably) is enable/disable of each of the Z*inx extensions provided?  If there is going to be a growing set of Z*inx extensions (as the text below suggests), then maybe there should be a separate CSR just for Z*inx extensions?  (This CSR would also then provide the answer to the above discovery question at a hardware level.)

 

Greg

 

What’s the correct discovery mechanism for Z[FDQ]inx? And I need Zfinx_Zfh as well, ZfinxV for vector, and to be able to allocate a Zfinx version of any future FP extension.

 

Thanks

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

E-mail: Tariq.Kurd@...

Company: Huawei technologies R&D (UK) Ltd I Address: 290 Park Avenue, Aztec West, Almondsbury, Bristol, Avon, BS32 4SY, UK      

 

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

--
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv


Greg Favor
 

On Thu, Feb 25, 2021 at 12:51 PM Mark Himelstein <markhimelstein@...> wrote:
Also I suggest we document the whole discovery story in one place. So if enable (and by association discovery) is CSR but parameters are config and if could differ between RVA and RVM, I suggest we put all of it together in one chapter or appendix (or elsewhere) so readers don't have to piece it together by looking in lots of places. Is this possible?

I think so.  Although wrt all the juicy details related with what tech-config is developing, this document will just have a high level description and some general details, and then a pointer to the spec/etc. that the tech-config TG eventually produces.

Tim, I'll sync up with you next week or so - to see where tech-config is at and to summarize my tentative thoughts wrt the above.

Greg


Tariq Kurd
 

Hi everyone,

 

Going back a long way in the thread – virtualization isn’t a consideration for Zfinx – it’s really an area saving for small embedded cores.

 

For the same reason I share Allen’s concerns about implementing V + Zfinx – it doesn’t make much sense, but I wouldn’t necessarily forbid it.

 

But for the hardware discovery and enable/disable – I agree that there must be a standard approach for this, not only for Zfinx, but also for Zfh and future posit formats etc.

 

Personally I don’t see any reason to disable Zfinx via a CSR, but if that means it follows a standard approach then I’m fine to follow that.

 

I can put “awaiting discovery mechanism” in the spec for the time being.

è Who will resolve the hardware approach?

 

I think the Zfinx spec should cover the discovery mechanism for F/D/Zfh + Zfinx configurations. Future FP and V + Zfinx, if required, can be specified by those task groups.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Greg Favor
Sent: 26 February 2021 06:03
To: Mark Himelstein <markhimelstein@...>
Cc: config <tech-config@...>; Tariq Kurd <tariq.kurd@...>; tech-unprivileged@...; Elisa Sawyer <elisa@...>
Subject: Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

On Thu, Feb 25, 2021 at 12:51 PM Mark Himelstein <markhimelstein@...> wrote:

Also I suggest we document the whole discovery story in one place. So if enable (and by association discovery) is CSR but parameters are config and if could differ between RVA and RVM, I suggest we put all of it together in one chapter or appendix (or elsewhere) so readers don't have to piece it together by looking in lots of places. Is this possible?

 

I think so.  Although wrt all the juicy details related with what tech-config is developing, this document will just have a high level description and some general details, and then a pointer to the spec/etc. that the tech-config TG eventually produces.

 

Tim, I'll sync up with you next week or so - to see where tech-config is at and to summarize my tentative thoughts wrt the above.

 

Greg

 


Tim Newsome <tim@...>
 

On Thu, Feb 25, 2021 at 10:03 PM Greg Favor <gfavor@...> wrote:
Tim, I'll sync up with you next week or so - to see where tech-config is at and to summarize my tentative thoughts wrt the above.

Sounds good. I look forward to it.

Tim


Abner Chang
 



Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> 於 2021年2月26日 週五 下午7:45寫道:

Hi everyone,

 

Going back a long way in the thread – virtualization isn’t a consideration for Zfinx – it’s really an area saving for small embedded cores.

 

For the same reason I share Allen’s concerns about implementing V + Zfinx – it doesn’t make much sense, but I wouldn’t necessarily forbid it.

 

But for the hardware discovery and enable/disable – I agree that there must be a standard approach for this, not only for Zfinx, but also for Zfh and future posit formats etc.

 

Personally I don’t see any reason to disable Zfinx via a CSR, but if that means it follows a standard approach then I’m fine to follow that.

 

I can put “awaiting discovery mechanism” in the spec for the time being.

è Who will resolve the hardware approach?

If you were asking the hardware approach to discover the configuration structure. As I can remember, also mention in the charter of the configuration structure working group, which is this group will deliver the specification for a method to discover and access to the configuration structures. This working group should come out with the proposal for review.
Tim, please correct me if I am wrong.

 

I think the Zfinx spec should cover the discovery mechanism for F/D/Zfh + Zfinx configurations. Future FP and V + Zfinx, if required, can be specified by those task groups.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Greg Favor
Sent: 26 February 2021 06:03
To: Mark Himelstein <markhimelstein@...>
Cc: config <tech-config@...>; Tariq Kurd <tariq.kurd@...>; tech-unprivileged@...; Elisa Sawyer <elisa@...>
Subject: Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

On Thu, Feb 25, 2021 at 12:51 PM Mark Himelstein <markhimelstein@...> wrote:

Also I suggest we document the whole discovery story in one place. So if enable (and by association discovery) is CSR but parameters are config and if could differ between RVA and RVM, I suggest we put all of it together in one chapter or appendix (or elsewhere) so readers don't have to piece it together by looking in lots of places. Is this possible?

 

I think so.  Although wrt all the juicy details related with what tech-config is developing, this document will just have a high level description and some general details, and then a pointer to the spec/etc. that the tech-config TG eventually produces.

 

Tim, I'll sync up with you next week or so - to see where tech-config is at and to summarize my tentative thoughts wrt the above.

 

Greg

 


Abner Chang
 



Abner Chang via lists.riscv.org <renba.chang=gmail.com@...> 於 2021年2月28日 週日 下午12:12寫道:


Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> 於 2021年2月26日 週五 下午7:45寫道:

Hi everyone,

 

Going back a long way in the thread – virtualization isn’t a consideration for Zfinx – it’s really an area saving for small embedded cores.

 

For the same reason I share Allen’s concerns about implementing V + Zfinx – it doesn’t make much sense, but I wouldn’t necessarily forbid it.

 

But for the hardware discovery and enable/disable – I agree that there must be a standard approach for this, not only for Zfinx, but also for Zfh and future posit formats etc.

 

Personally I don’t see any reason to disable Zfinx via a CSR, but if that means it follows a standard approach then I’m fine to follow that.

 

I can put “awaiting discovery mechanism” in the spec for the time being.

è Who will resolve the hardware approach?

If you were asking the hardware approach to discover the configuration structure. As I can remember, also mention in the charter of the configuration structure working group, which is this group will deliver the specification for a method to discover and access to the configuration structures. This working group should come out with the proposal for review.
Tim, please correct me if I am wrong.
Never mind, I  think the hardware approach refers to the discovery through CSR as Greg mention. 

 

I think the Zfinx spec should cover the discovery mechanism for F/D/Zfh + Zfinx configurations. Future FP and V + Zfinx, if required, can be specified by those task groups.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Greg Favor
Sent: 26 February 2021 06:03
To: Mark Himelstein <markhimelstein@...>
Cc: config <tech-config@...>; Tariq Kurd <tariq.kurd@...>; tech-unprivileged@...; Elisa Sawyer <elisa@...>
Subject: Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

On Thu, Feb 25, 2021 at 12:51 PM Mark Himelstein <markhimelstein@...> wrote:

Also I suggest we document the whole discovery story in one place. So if enable (and by association discovery) is CSR but parameters are config and if could differ between RVA and RVM, I suggest we put all of it together in one chapter or appendix (or elsewhere) so readers don't have to piece it together by looking in lots of places. Is this possible?

 

I think so.  Although wrt all the juicy details related with what tech-config is developing, this document will just have a high level description and some general details, and then a pointer to the spec/etc. that the tech-config TG eventually produces.

 

Tim, I'll sync up with you next week or so - to see where tech-config is at and to summarize my tentative thoughts wrt the above.

 

Greg

 


Tariq Kurd
 

>Never mind, I  think the hardware approach refers to the discovery through CSR as Greg mention. 

Yes, that’s what I’m referring to. I’ll wait for a standard CSR based discovery method for extensions which don't fit in MISA, for the Zfinx spec.

 

Tariq

 

From: Abner Chang [mailto:renba.chang@...]
Sent: 28 February 2021 04:27
To: tech-unprivileged@...; Renba <renba.chang@...>
Cc: Tariq Kurd <tariq.kurd@...>; gfavor@...; Mark Himelstein <markhimelstein@...>; config <tech-config@...>; Elisa Sawyer <elisa@...>
Subject: Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

 

 

Abner Chang via lists.riscv.org <renba.chang=gmail.com@...> 2021228 週日 下午12:12寫道:

 

 

Tariq Kurd via lists.riscv.org <tariq.kurd=huawei.com@...> 2021226 週五 下午7:45寫道:

Hi everyone,

 

Going back a long way in the thread – virtualization isn’t a consideration for Zfinx – it’s really an area saving for small embedded cores.

 

For the same reason I share Allen’s concerns about implementing V + Zfinx – it doesn’t make much sense, but I wouldn’t necessarily forbid it.

 

But for the hardware discovery and enable/disable – I agree that there must be a standard approach for this, not only for Zfinx, but also for Zfh and future posit formats etc.

 

Personally I don’t see any reason to disable Zfinx via a CSR, but if that means it follows a standard approach then I’m fine to follow that.

 

I can put “awaiting discovery mechanism” in the spec for the time being.

è Who will resolve the hardware approach?

If you were asking the hardware approach to discover the configuration structure. As I can remember, also mention in the charter of the configuration structure working group, which is this group will deliver the specification for a method to discover and access to the configuration structures. This working group should come out with the proposal for review.

Tim, please correct me if I am wrong.

Never mind, I  think the hardware approach refers to the discovery through CSR as Greg mention. 

 

I think the Zfinx spec should cover the discovery mechanism for F/D/Zfh + Zfinx configurations. Future FP and V + Zfinx, if required, can be specified by those task groups.

 

Tariq

 

From: tech-unprivileged@... [mailto:tech-unprivileged@...] On Behalf Of Greg Favor
Sent: 26 February 2021 06:03
To: Mark Himelstein <markhimelstein@...>
Cc: config <tech-config@...>; Tariq Kurd <tariq.kurd@...>; tech-unprivileged@...; Elisa Sawyer <elisa@...>
Subject: Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-config] Discovery mechanism for Zfinx

 

On Thu, Feb 25, 2021 at 12:51 PM Mark Himelstein <markhimelstein@...> wrote:

Also I suggest we document the whole discovery story in one place. So if enable (and by association discovery) is CSR but parameters are config and if could differ between RVA and RVM, I suggest we put all of it together in one chapter or appendix (or elsewhere) so readers don't have to piece it together by looking in lots of places. Is this possible?

 

I think so.  Although wrt all the juicy details related with what tech-config is developing, this document will just have a high level description and some general details, and then a pointer to the spec/etc. that the tech-config TG eventually produces.

 

Tim, I'll sync up with you next week or so - to see where tech-config is at and to summarize my tentative thoughts wrt the above.

 

Greg