1. Tech-Privileged
  2. Topics

Proposal for Custom Values in satp

Bill Huffman
 


On 8/3/20 7:01 AM, Jonathan Behrens wrote:
EXTERNAL MAIL

>For RV32, values with satp[31] clear and satp[30:0] non-zero are reserved.  I propose that values with satp[31] clear and satp[30:29]=0x3 be defined as Custom.

Are 7 bits enough , for ASID?


It depends on how you are using them. For x86-64, Linux actually only uses 4 ASID bits (out of the 12 available) because it assigns them per-core and recycles them aggressively. However, if you instead try to have globally unique ASIDs then you might need far more than 7 bits.

Jonathan

Agreed, but the proposal doesn't assume that a custom implementation will use the bits of satp in the same way the priv spec uses them.  The bits may well be used in a different fashion.

Of course, as with instruction opcodes, an implementation is free also to used reserved encodings if the implementers are willing to have a possible conflict with future standard extensions.

      Bill
Jonathan Behrens <behrensj@...>
 

>For RV32, values with satp[31] clear and satp[30:0] non-zero are reserved.  I propose that values with satp[31] clear and satp[30:29]=0x3 be defined as Custom.

Are 7 bits enough , for ASID?


It depends on how you are using them. For x86-64, Linux actually only uses 4 ASID bits (out of the 12 available) because it assigns them per-core and recycles them aggressively. However, if you instead try to have globally unique ASIDs then you might need far more than 7 bits.

Jonathan
Andrea Mondelli <andrea.mondelli@...>
 

>For RV32, values with satp[31] clear and satp[30:0] non-zero are reserved.  I propose that values with satp[31] clear and satp[30:29]=0x3 be defined as Custom.

Are 7 bits enough , for ASID?

 
Bill Huffman
 

Looks appropriate to me.     Bill

On 7/31/20 4:22 PM, Andrew Waterman wrote:

EXTERNAL MAIL

I've written the idea up so it doesn't get lost, but others should still feel free to comment.  In the meantime, can you sanity-check my patch?  https://github.com/riscv/riscv-isa-manual/commit/f7710a02da497a721095a0252041122a6d0e0a6c

On Thu, Jul 30, 2020 at 10:26 AM Allen Baum <allen.baum@...> wrote:
That sounds like a no brainer good idea.

-Allen

On Jul 29, 2020, at 2:41 PM, Andrew Waterman <andrew@...> wrote:

I support this proposal.

On Wed, Jul 29, 2020 at 12:42 PM Bill Huffman <huffman@...> wrote:

The satp register has reserved values.  Some implementers will, no doubt, want to define non-standard behavior based on satp.  I would like to propose that we define some of the reserved values in satp as Custom now so that those who do so won't head in diverging directions.

For RV64, there are 11 reserved values of the Mode field.  I propose that the encodings 14 and 15 be defined as Custom.

For RV32, values with satp[31] clear and satp[30:0] non-zero are reserved.  I propose that values with satp[31] clear and satp[30:29]=0x3 be defined as Custom.

The RV32 encoding is not perfect.  To have the largest contiguous space free, we need to pick bits at the top or bottom.  Top bits encroach on what's now ASID space while bottom bits encroach on what's now PPN space.  The former seemed a bit better.

       Bill
andrew@...
 

I've written the idea up so it doesn't get lost, but others should still feel free to comment.  In the meantime, can you sanity-check my patch?  https://github.com/riscv/riscv-isa-manual/commit/f7710a02da497a721095a0252041122a6d0e0a6c


On Thu, Jul 30, 2020 at 10:26 AM Allen Baum <allen.baum@...> wrote:
That sounds like a no brainer good idea.

-Allen

On Jul 29, 2020, at 2:41 PM, Andrew Waterman <andrew@...> wrote:

I support this proposal.

On Wed, Jul 29, 2020 at 12:42 PM Bill Huffman <huffman@...> wrote:

The satp register has reserved values.  Some implementers will, no doubt, want to define non-standard behavior based on satp.  I would like to propose that we define some of the reserved values in satp as Custom now so that those who do so won't head in diverging directions.

For RV64, there are 11 reserved values of the Mode field.  I propose that the encodings 14 and 15 be defined as Custom.

For RV32, values with satp[31] clear and satp[30:0] non-zero are reserved.  I propose that values with satp[31] clear and satp[30:29]=0x3 be defined as Custom.

The RV32 encoding is not perfect.  To have the largest contiguous space free, we need to pick bits at the top or bottom.  Top bits encroach on what's now ASID space while bottom bits encroach on what's now PPN space.  The former seemed a bit better.

       Bill
Allen Baum
 

That sounds like a no brainer good idea.

-Allen

On Jul 29, 2020, at 2:41 PM, Andrew Waterman <andrew@...> wrote:

I support this proposal.

On Wed, Jul 29, 2020 at 12:42 PM Bill Huffman <huffman@...> wrote:

The satp register has reserved values.  Some implementers will, no doubt, want to define non-standard behavior based on satp.  I would like to propose that we define some of the reserved values in satp as Custom now so that those who do so won't head in diverging directions.

For RV64, there are 11 reserved values of the Mode field.  I propose that the encodings 14 and 15 be defined as Custom.

For RV32, values with satp[31] clear and satp[30:0] non-zero are reserved.  I propose that values with satp[31] clear and satp[30:29]=0x3 be defined as Custom.

The RV32 encoding is not perfect.  To have the largest contiguous space free, we need to pick bits at the top or bottom.  Top bits encroach on what's now ASID space while bottom bits encroach on what's now PPN space.  The former seemed a bit better.

       Bill
andrew@...
 

I support this proposal.


On Wed, Jul 29, 2020 at 12:42 PM Bill Huffman <huffman@...> wrote:

The satp register has reserved values.  Some implementers will, no doubt, want to define non-standard behavior based on satp.  I would like to propose that we define some of the reserved values in satp as Custom now so that those who do so won't head in diverging directions.

For RV64, there are 11 reserved values of the Mode field.  I propose that the encodings 14 and 15 be defined as Custom.

For RV32, values with satp[31] clear and satp[30:0] non-zero are reserved.  I propose that values with satp[31] clear and satp[30:29]=0x3 be defined as Custom.

The RV32 encoding is not perfect.  To have the largest contiguous space free, we need to pick bits at the top or bottom.  Top bits encroach on what's now ASID space while bottom bits encroach on what's now PPN space.  The former seemed a bit better.

       Bill
Bill Huffman
 

The satp register has reserved values.  Some implementers will, no doubt, want to define non-standard behavior based on satp.  I would like to propose that we define some of the reserved values in satp as Custom now so that those who do so won't head in diverging directions.

For RV64, there are 11 reserved values of the Mode field.  I propose that the encodings 14 and 15 be defined as Custom.

For RV32, values with satp[31] clear and satp[30:0] non-zero are reserved.  I propose that values with satp[31] clear and satp[30:29]=0x3 be defined as Custom.

The RV32 encoding is not perfect.  To have the largest contiguous space free, we need to pick bits at the top or bottom.  Top bits encroach on what's now ASID space while bottom bits encroach on what's now PPN space.  The former seemed a bit better.

       Bill

1 - 8 of 8