isa_conflict_resolution/ioctl.mdwn

   1 # ioctl-like
   2
   3 ==RB===
   4
   5 This proposal adds a standardised extension interface to the RV
   6 instruction set by introducing a fixed small number (e.g. 8) of
   7 "overloadable" R-type opcodes ext_ctl0, .. ext_ctl7. Each takes a process
   8 local interface cookie in rs1. Based on the cookie, the CPU routes the
   9 "overloaded" instructions to a "device" on or off the CPU that implements
  10 the actual semantics.
  11
  12 The cookie is "opened" with an additional R-type instruction ext_open that
  13 takes a 20 bit identifier and "closed" with an  ext_close instruction. The
  14 implementing hardware device can use the cookie to reference internal
  15 state. Thus, interfaces may be statefull.
  16
  17 CPU's and devices may implement several interfaces, indeed, are expected
  18 to. E.g. a single hardware device might expose a functional interface with
  19 6 overloaded instructions, expose configuration with two highly device
  20 specific management interfaces with 8 resp. 4 overloaded instructions,
  21 and respond to a standardised save state interface with 4 overloaded
  22 instructions.
  23
  24 Having a standardised overloadable interface simply avoids much of the
  25 need for isa extensions for hardware with non standard interfaces and
  26 semantics. This is analogous to the way that the standardised overloadable
  27 ioctl interface of the kernel almost completely avoids the need for
  28 extending the kernel with syscalls for the myriad of hardware devices
  29 with their specific interfaces and semantics.
  30
  31 Since the rs1 input of the overloaded  ext_ctl instruction's are taken
  32 by the interface cookie, they are restricted in use compared to a normal
  33 R-type instruction (it is possible to pass 12 bits of additional info by
  34 or ing it with the cookie). Delegation is also expected to come at a small
  35 additional performance price compared to a "native" instruction. This
  36 should be an acceptable tradeoff in most cases.
  37
  38 The expanded flexibility comes at the cost: the standard can specify the
  39 semantics of the delegation mechanism and the interfacing with the rest
  40 of the cpu, but the actual semantics of the overloaded instructions can
  41 only be defined by the designer of the interface. Likewise, a device
  42 can be conforming as far as delegation and interaction with the CPU
  43 is concerned, but whether the hardware is conforming to the semantics
  44 of the interface is outside the scope of spec. Being able to specify
  45 that semantics using the methods used for RV itself is clearly very
  46 valuable. One impetus for doing that is using it for purposes of its own,
  47 effectively freeing opcode space for other purposes. Also, some interfaces
  48 may become de facto or de jure standards themselves, necessitating
  49 hardware to implement competing interfaces. I.e., facilitating a free
  50 for all, may lead to standards proliferation. C'est la vie.
  51
  52 The only "ISA-collisions" that can still occur are in the 20 bit (~10^6)
  53 interface identifier space, with 12 more bits to identify a device on
  54 a hart that implements the interface. One suggestion is setting aside
  55 2^19 id's that are handed out for a small fee by a central (automated)
  56 registration (making sure the space is not just claimed), while the
  57 remaining 2^19 are used as a good hash on a long, plausibly globally
  58 unique human readable interface name. This gives implementors the choice
  59 between a guaranteed private identifier paying a fee, or relying on low
  60 probabilities. The interface identifier could also easily be extended
  61 to 42 bits on RV64.
  62
  63
  64 ====End RB==
  65
  66 This proposal basically mirrors the concept of POSIX ioctls, providing
  67 (arbitrarily) 8 functions (opcodes) whose meaning may be over-ridden
  68 in an object-orientated fashion by calling an "open handle" (and close)
  69 function (instruction) that switches (redirects) the 8 functions over to
  70 different opcodes.
  71
  72
  73 The "open handle" opcode takes a GUID (globally-unique identifier)
  74 and an ioctl number, and stores the UUID in a table indexed by the
  75 ioctl number:
  76
  77     char handle_global_state[8][20] # stores UUID or index of same
  78
  79     void open_handle(char[20] uuid, byte ioctl_num):
  80           handle_global_state[ioctl_num] = uuid
  81
  82     void close_handle(byte ioctl_num):
  83           handle_global_state[ioctl_num] = -1 # clear table entry
  84
  85 "Ioctls" (arbitrarily 8 separate R-type opcodes) then perform a redirect
  86 based on what the global state for that numbered "ioctl" has been set to:
  87
  88     ioctl_fn0(funct7, rs2, rs1, funct3, rd): # all r-type bits
  89     {
  90         if (handle_global_state[0] == CUSTOMEXT1UUID)
  91            CUSTEXT1_FN0(funct7, rs2, rs1, funct3, rd); # all r-type bits
  92         else if (handle_global_state[0] == CUSTOMEXT2UUID)
  93            CUSTEXT2_FN0(funct7, rs2, rs1, funct3, rd, opcode); # all r-type bits
  94         else
  95             raise Exception("undefined opcode")
  96     }
  97
  98 Note that the "ioctl" receives all R-type bits (31:7) with the exception of the
  99 opcode (6:0).
 100
 101 === RB ==
 102
 103 not quite I think. It is more like
 104
 105 // Hardware, implementing interface with UUID 0xABCD
 106
 107     def A_shutdown(cookie, data):
 108        ...
 109
 110     def A_init(data)
 111
 112     def A_do_stuff(cookie, data):
 113        ...
 114
 115     def A_do_more_stuff(cookie, data):
 116        ...
 117
 118     interfaceA = {
 119                   "shutdown": A_shutdown,
 120                   "init":     A_init,
 121                   "ctl0":     A_do_stuff,
 122                   "ctl1":     A_do_more_stuff
 123                  }
 124
 125 // hardware implementing interface with UUID = 0x1234
 126
 127     def B_do_things(cookie, data):
 128        ...
 129     def B_shutdown(cookie, data)
 130        ...
 131
 132     interfaceB = {
 133                   "shutdown": B_shutdown,
 134                   "ctl0":     B_do_things
 135                  }
 136
 137
 138 // The CPU being wired to the devices
 139
 140     cpu_interfaces = {
 141                   0xABCD: interfaceA,
 142                   0x1234: interfaceB
 143                  }
 144
 145 // The functionality that the CPU must implement to use the extension interface
 146
 147     cpu_open_handles = {}
 148
 149     __handleId = 0
 150     def new_unused_handle_id()
 151         __handleId = __handleId + 1
 152         return __handleId
 153
 154     def ext_open(uuid, data):
 155         interface = cpu_interface[uuid]
 156         if interface == NIL:
 157             raise Exception("No such interface")
 158
 159         handleId = new_unused_handle_id()
 160         cpu_open_handles[handleId] = (interface,
 161                                       CurrentVirtualMemoryAddressSpace)
 162
 163         cookie = A_init(data)                      # Here device takes over
 164
 165         return (handle_id, cookie)
 166
 167     def ext_close(handle, data):
 168         (handleId, cookie) = handle
 169         intf_VMA = cpu_open_handles[handleId]
 170         if intf_VMA == NIL:
 171              return -1
 172
 173         (interface, VMA) = intf_VMA
 174         if VMA != CurrentVirtualMemoryAddressSpace:
 175              return -1
 176         assert(interface != NIL)
 177         shutdown = interface["shutdown"]
 178         if shutdown != NIL:
 179
 180              err = interface.shutdown(cookie, data)  # Here device takes over
 181
 182              if err != 0:
 183                  return err
 184         cpu_open_handles[handleId] = NIL
 185         return 0
 186
 187     def ext_ctl0(handle, data):
 188         (handleId, cookie) = handle
 189         intf_VMA = cpu_open_handles[handleId]
 190         if intf_VMA == NIL:
 191              raise Exception("No such interface")
 192
 193         (interface, VMA) = intf_VMA
 194         if VMA != CurrentVirtualMemoryAddressSpace:
 195              raise Exception("No such interface")  # Disclosing that the
 196                                                    # interface exists in
 197                                                    # different address is
 198                                                    # security hole
 199
 200         assert(interface != NIL)
 201         ctl0 = interface["ctl0"]
 202         if ctl0 == NIL:
 203             raise Exception("No such Instruction")
 204
 205         return ctl0(cookie, data)                  # Here device takes over
 206
 207
 208 The other ext_ctl's are similar.
 209
 210 ==End RB==
 211
 212
 213
 214
 215 The proposal is functionally near-identical to that of the mvendor/march-id
 216 except extended down to individual opcodes.  As such it could hypothetically
 217 be proposed as an independent Standard Extension in its own right that extends
 218 the Custom Opcode space *or* fits into the brownfield spaces within the
 219 existing ISA opcode space *or* is used as the basis of an independent
 220 Custom Extension in its own right.
 221
 222 ==RB==
 223 I really think it should be in browncode
 224 ==RB==
 225
 226 One of the reasons for seeking an extension of the Custom opcode space is
 227 that the Custom opcode space is severely limited: only 2 opcodes are free
 228 within the 32-bit space, and only four total remain in the 48 and 64-bit
 229 space.
 230
 231 Despite the proposal (which is still undergoing clarification)
 232 being worthwhile in its own right, and standing on its own merits and
 233 thus definitely worthwhile pursuing, it is non-trivial and much more
 234 invasive than the mvendor/march-id WARL concept.
 235
 236
 237