linux/arch/tile/include/hv/iorpc.h
<<
>>
Prefs
   1/*
   2 * Copyright 2012 Tilera Corporation. All Rights Reserved.
   3 *
   4 *   This program is free software; you can redistribute it and/or
   5 *   modify it under the terms of the GNU General Public License
   6 *   as published by the Free Software Foundation, version 2.
   7 *
   8 *   This program is distributed in the hope that it will be useful, but
   9 *   WITHOUT ANY WARRANTY; without even the implied warranty of
  10 *   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
  11 *   NON INFRINGEMENT.  See the GNU General Public License for
  12 *   more details.
  13 */
  14#ifndef _HV_IORPC_H_
  15#define _HV_IORPC_H_
  16
  17/**
  18 *
  19 * Error codes and struct definitions for the IO RPC library.
  20 *
  21 * The hypervisor's IO RPC component provides a convenient way for
  22 * driver authors to proxy system calls between user space, linux, and
  23 * the hypervisor driver.  The core of the system is a set of Python
  24 * files that take ".idl" files as input and generates the following
  25 * source code:
  26 *
  27 * - _rpc_call() routines for use in userspace IO libraries.  These
  28 * routines take an argument list specified in the .idl file, pack the
  29 * arguments in to a buffer, and read or write that buffer via the
  30 * Linux iorpc driver.
  31 *
  32 * - dispatch_read() and dispatch_write() routines that hypervisor
  33 * drivers can use to implement most of their dev_pread() and
  34 * dev_pwrite() methods.  These routines decode the incoming parameter
  35 * blob, permission check and translate parameters where appropriate,
  36 * and then invoke a callback routine for whichever RPC call has
  37 * arrived.  The driver simply implements the set of callback
  38 * routines.
  39 *
  40 * The IO RPC system also includes the Linux 'iorpc' driver, which
  41 * proxies calls between the userspace library and the hypervisor
  42 * driver.  The Linux driver is almost entirely device agnostic; it
  43 * watches for special flags indicating cases where a memory buffer
  44 * address might need to be translated, etc.  As a result, driver
  45 * writers can avoid many of the problem cases related to registering
  46 * hardware resources like memory pages or interrupts.  However, the
  47 * drivers must be careful to obey the conventions documented below in
  48 * order to work properly with the generic Linux iorpc driver.
  49 *
  50 * @section iorpc_domains Service Domains
  51 *
  52 * All iorpc-based drivers must support a notion of service domains.
  53 * A service domain is basically an application context - state
  54 * indicating resources that are allocated to that particular app
  55 * which it may access and (perhaps) other applications may not
  56 * access.  Drivers can support any number of service domains they
  57 * choose.  In some cases the design is limited by a number of service
  58 * domains supported by the IO hardware; in other cases the service
  59 * domains are a purely software concept and the driver chooses a
  60 * maximum number of domains based on how much state memory it is
  61 * willing to preallocate.
  62 *
  63 * For example, the mPIPE driver only supports as many service domains
  64 * as are supported by the mPIPE hardware.  This limitation is
  65 * required because the hardware implements its own MMIO protection
  66 * scheme to allow large MMIO mappings while still protecting small
  67 * register ranges within the page that should only be accessed by the
  68 * hypervisor.
  69 *
  70 * In contrast, drivers with no hardware service domain limitations
  71 * (for instance the TRIO shim) can implement an arbitrary number of
  72 * service domains.  In these cases, each service domain is limited to
  73 * a carefully restricted set of legal MMIO addresses if necessary to
  74 * keep one application from corrupting another application's state.
  75 *
  76 * @section iorpc_conventions System Call Conventions
  77 *
  78 * The driver's open routine is responsible for allocating a new
  79 * service domain for each hv_dev_open() call.  By convention, the
  80 * return value from open() should be the service domain number on
  81 * success, or GXIO_ERR_NO_SVC_DOM if no more service domains are
  82 * available.
  83 *
  84 * The implementations of hv_dev_pread() and hv_dev_pwrite() are
  85 * responsible for validating the devhdl value passed up by the
  86 * client.  Since the device handle returned by hv_dev_open() should
  87 * embed the positive service domain number, drivers should make sure
  88 * that DRV_HDL2BITS(devhdl) is a legal service domain.  If the client
  89 * passes an illegal service domain number, the routine should return
  90 * GXIO_ERR_INVAL_SVC_DOM.  Once the service domain number has been
  91 * validated, the driver can copy to/from the client buffer and call
  92 * the dispatch_read() or dispatch_write() methods created by the RPC
  93 * generator.
  94 *
  95 * The hv_dev_close() implementation should reset all service domain
  96 * state and put the service domain back on a free list for
  97 * reallocation by a future application.  In most cases, this will
  98 * require executing a hardware reset or drain flow and denying any
  99 * MMIO regions that were created for the service domain.
 100 *
 101 * @section iorpc_data Special Data Types
 102 *
 103 * The .idl file syntax allows the creation of syscalls with special
 104 * parameters that require permission checks or translations as part
 105 * of the system call path.  Because of limitations in the code
 106 * generator, APIs are generally limited to just one of these special
 107 * parameters per system call, and they are sometimes required to be
 108 * the first or last parameter to the call.  Special parameters
 109 * include:
 110 *
 111 * @subsection iorpc_mem_buffer MEM_BUFFER
 112 *
 113 * The MEM_BUFFER() datatype allows user space to "register" memory
 114 * buffers with a device.  Registering memory accomplishes two tasks:
 115 * Linux keeps track of all buffers that might be modified by a
 116 * hardware device, and the hardware device drivers bind registered
 117 * buffers to particular hardware resources like ingress NotifRings.
 118 * The MEM_BUFFER() idl syntax can take extra flags like ALIGN_64KB,
 119 * ALIGN_SELF_SIZE, and FLAGS indicating that memory buffers must have
 120 * certain alignment or that the user should be able to pass a "memory
 121 * flags" word specifying attributes like nt_hint or IO cache pinning.
 122 * The parser will accept multiple MEM_BUFFER() flags.
 123 *
 124 * Implementations must obey the following conventions when
 125 * registering memory buffers via the iorpc flow.  These rules are a
 126 * result of the Linux driver implementation, which needs to keep
 127 * track of how many times a particular page has been registered with
 128 * the hardware so that it can release the page when all those
 129 * registrations are cleared.
 130 *
 131 * - Memory registrations that refer to a resource which has already
 132 * been bound must return GXIO_ERR_ALREADY_INIT.  Thus, it is an
 133 * error to register memory twice without resetting (i.e. closing) the
 134 * resource in between.  This convention keeps the Linux driver from
 135 * having to track which particular devices a page is bound to.
 136 *
 137 * - At present, a memory registration is only cleared when the
 138 * service domain is reset.  In this case, the Linux driver simply
 139 * closes the HV device file handle and then decrements the reference
 140 * counts of all pages that were previously registered with the
 141 * device.
 142 *
 143 * - In the future, we may add a mechanism for unregistering memory.
 144 * One possible implementation would require that the user specify
 145 * which buffer is currently registered.  The HV would then verify
 146 * that that page was actually the one currently mapped and return
 147 * success or failure to Linux, which would then only decrement the
 148 * page reference count if the addresses were mapped.  Another scheme
 149 * might allow Linux to pass a token to the HV to be returned when the
 150 * resource is unmapped.
 151 *
 152 * @subsection iorpc_interrupt INTERRUPT
 153 *
 154 * The INTERRUPT .idl datatype allows the client to bind hardware
 155 * interrupts to a particular combination of IPI parameters - CPU, IPI
 156 * PL, and event bit number.  This data is passed via a special
 157 * datatype so that the Linux driver can validate the CPU and PL and
 158 * the HV generic iorpc code can translate client CPUs to real CPUs.
 159 *
 160 * @subsection iorpc_pollfd_setup POLLFD_SETUP
 161 *
 162 * The POLLFD_SETUP .idl datatype allows the client to set up hardware
 163 * interrupt bindings which are received by Linux but which are made
 164 * visible to user processes as state transitions on a file descriptor;
 165 * this allows user processes to use Linux primitives, such as poll(), to
 166 * await particular hardware events.  This data is passed via a special
 167 * datatype so that the Linux driver may recognize the pollable file
 168 * descriptor and translate it to a set of interrupt target information,
 169 * and so that the HV generic iorpc code can translate client CPUs to real
 170 * CPUs.
 171 *
 172 * @subsection iorpc_pollfd POLLFD
 173 *
 174 * The POLLFD .idl datatype allows manipulation of hardware interrupt
 175 * bindings set up via the POLLFD_SETUP datatype; common operations are
 176 * resetting the state of the requested interrupt events, and unbinding any
 177 * bound interrupts.  This data is passed via a special datatype so that
 178 * the Linux driver may recognize the pollable file descriptor and
 179 * translate it to an interrupt identifier previously supplied by the
 180 * hypervisor as the result of an earlier pollfd_setup operation.
 181 *
 182 * @subsection iorpc_blob BLOB
 183 *
 184 * The BLOB .idl datatype allows the client to write an arbitrary
 185 * length string of bytes up to the hypervisor driver.  This can be
 186 * useful for passing up large, arbitrarily structured data like
 187 * classifier programs.  The iorpc stack takes care of validating the
 188 * buffer VA and CPA as the data passes up to the hypervisor.  Unlike
 189 * MEM_BUFFER(), the buffer is not registered - Linux does not bump
 190 * page refcounts and the HV driver should not reuse the buffer once
 191 * the system call is complete.
 192 *
 193 * @section iorpc_translation Translating User Space Calls
 194 *
 195 * The ::iorpc_offset structure describes the formatting of the offset
 196 * that is passed to pread() or pwrite() as part of the generated RPC code.
 197 * When the user calls up to Linux, the rpc code fills in all the fields of
 198 * the offset, including a 16-bit opcode, a 16 bit format indicator, and 32
 199 * bits of user-specified "sub-offset".  The opcode indicates which syscall
 200 * is being requested.  The format indicates whether there is a "prefix
 201 * struct" at the start of the memory buffer passed to pwrite(), and if so
 202 * what data is in that prefix struct.  These prefix structs are used to
 203 * implement special datatypes like MEM_BUFFER() and INTERRUPT - we arrange
 204 * to put data that needs translation and permission checks at the start of
 205 * the buffer so that the Linux driver and generic portions of the HV iorpc
 206 * code can easily access the data.  The 32 bits of user-specified
 207 * "sub-offset" are most useful for pread() calls where the user needs to
 208 * also pass in a few bits indicating which register to read, etc.
 209 *
 210 * The Linux iorpc driver watches for system calls that contain prefix
 211 * structs so that it can translate parameters and bump reference
 212 * counts as appropriate.  It does not (currently) have any knowledge
 213 * of the per-device opcodes - it doesn't care what operation you're
 214 * doing to mPIPE, so long as it can do all the generic book-keeping.
 215 * The hv/iorpc.h header file defines all of the generic encoding bits
 216 * needed to translate iorpc calls without knowing which particular
 217 * opcode is being issued.
 218 *
 219 * @section iorpc_globals Global iorpc Calls
 220 *
 221 * Implementing mmap() required adding some special iorpc syscalls
 222 * that are only called by the Linux driver, never by userspace.
 223 * These include get_mmio_base() and check_mmio_offset().  These
 224 * routines are described in globals.idl and must be included in every
 225 * iorpc driver.  By providing these routines in every driver, Linux's
 226 * mmap implementation can easily get the PTE bits it needs and
 227 * validate the PA offset without needing to know the per-device
 228 * opcodes to perform those tasks.
 229 *
 230 * @section iorpc_kernel Supporting gxio APIs in the Kernel
 231 *
 232 * The iorpc code generator also supports generation of kernel code
 233 * implementing the gxio APIs.  This capability is currently used by
 234 * the mPIPE network driver, and will likely be used by the TRIO root
 235 * complex and endpoint drivers and perhaps an in-kernel crypto
 236 * driver.  Each driver that wants to instantiate iorpc calls in the
 237 * kernel needs to generate a kernel version of the generate rpc code
 238 * and (probably) copy any related gxio source files into the kernel.
 239 * The mPIPE driver provides a good example of this pattern.
 240 */
 241
 242#ifdef __KERNEL__
 243#include <linux/stddef.h>
 244#else
 245#include <stddef.h>
 246#endif
 247
 248#if defined(__HV__)
 249#include <hv/hypervisor.h>
 250#elif defined(__KERNEL__)
 251#include <hv/hypervisor.h>
 252#include <linux/types.h>
 253#else
 254#include <stdint.h>
 255#endif
 256
 257
 258/** Code indicating translation services required within the RPC path.
 259 * These indicate whether there is a translatable struct at the start
 260 * of the RPC buffer and what information that struct contains.
 261 */
 262enum iorpc_format_e
 263{
 264  /** No translation required, no prefix struct. */
 265  IORPC_FORMAT_NONE,
 266
 267  /** No translation required, no prefix struct, no access to this
 268   *  operation from user space. */
 269  IORPC_FORMAT_NONE_NOUSER,
 270
 271  /** Prefix struct contains user VA and size. */
 272  IORPC_FORMAT_USER_MEM,
 273
 274  /** Prefix struct contains CPA, size, and homing bits. */
 275  IORPC_FORMAT_KERNEL_MEM,
 276
 277  /** Prefix struct contains interrupt. */
 278  IORPC_FORMAT_KERNEL_INTERRUPT,
 279
 280  /** Prefix struct contains user-level interrupt. */
 281  IORPC_FORMAT_USER_INTERRUPT,
 282
 283  /** Prefix struct contains pollfd_setup (interrupt information). */
 284  IORPC_FORMAT_KERNEL_POLLFD_SETUP,
 285
 286  /** Prefix struct contains user-level pollfd_setup (file descriptor). */
 287  IORPC_FORMAT_USER_POLLFD_SETUP,
 288
 289  /** Prefix struct contains pollfd (interrupt cookie). */
 290  IORPC_FORMAT_KERNEL_POLLFD,
 291
 292  /** Prefix struct contains user-level pollfd (file descriptor). */
 293  IORPC_FORMAT_USER_POLLFD,
 294};
 295
 296
 297/** Generate an opcode given format and code. */
 298#define IORPC_OPCODE(FORMAT, CODE) (((FORMAT) << 16) | (CODE))
 299
 300/** The offset passed through the read() and write() system calls
 301    combines an opcode with 32 bits of user-specified offset. */
 302union iorpc_offset
 303{
 304#ifndef __BIG_ENDIAN__
 305  uint64_t offset;              /**< All bits. */
 306
 307  struct
 308  {
 309    uint16_t code;              /**< RPC code. */
 310    uint16_t format;            /**< iorpc_format_e */
 311    uint32_t sub_offset;        /**< caller-specified offset. */
 312  };
 313
 314  uint32_t opcode;              /**< Opcode combines code & format. */
 315#else
 316  uint64_t offset;              /**< All bits. */
 317
 318  struct
 319  {
 320    uint32_t sub_offset;        /**< caller-specified offset. */
 321    uint16_t format;            /**< iorpc_format_e */
 322    uint16_t code;              /**< RPC code. */
 323  };
 324
 325  struct
 326  {
 327    uint32_t padding;
 328    uint32_t opcode;              /**< Opcode combines code & format. */
 329  };
 330#endif
 331};
 332
 333
 334/** Homing and cache hinting bits that can be used by IO devices. */
 335struct iorpc_mem_attr
 336{
 337  unsigned int lotar_x:4;       /**< lotar X bits (or Gx page_mask). */
 338  unsigned int lotar_y:4;       /**< lotar Y bits (or Gx page_offset). */
 339  unsigned int hfh:1;           /**< Uses hash-for-home. */
 340  unsigned int nt_hint:1;       /**< Non-temporal hint. */
 341  unsigned int io_pin:1;        /**< Only fill 'IO' cache ways. */
 342};
 343
 344/** Set the nt_hint bit. */
 345#define IORPC_MEM_BUFFER_FLAG_NT_HINT (1 << 0)
 346
 347/** Set the IO pin bit. */
 348#define IORPC_MEM_BUFFER_FLAG_IO_PIN (1 << 1)
 349
 350
 351/** A structure used to describe memory registration.  Different
 352    protection levels describe memory differently, so this union
 353    contains all the different possible descriptions.  As a request
 354    moves up the call chain, each layer translates from one
 355    description format to the next.  In particular, the Linux iorpc
 356    driver translates user VAs into CPAs and homing parameters. */
 357union iorpc_mem_buffer
 358{
 359  struct
 360  {
 361    uint64_t va;                /**< User virtual address. */
 362    uint64_t size;              /**< Buffer size. */
 363    unsigned int flags;         /**< nt_hint, IO pin. */
 364  }
 365  user;                         /**< Buffer as described by user apps. */
 366
 367  struct
 368  {
 369    unsigned long long cpa;     /**< Client physical address. */
 370#if defined(__KERNEL__) || defined(__HV__)
 371    size_t size;                /**< Buffer size. */
 372    HV_PTE pte;                 /**< PTE describing memory homing. */
 373#else
 374    uint64_t size;
 375    uint64_t pte;
 376#endif
 377    unsigned int flags;         /**< nt_hint, IO pin. */
 378  }
 379  kernel;                       /**< Buffer as described by kernel. */
 380
 381  struct
 382  {
 383    unsigned long long pa;      /**< Physical address. */
 384    size_t size;                /**< Buffer size. */
 385    struct iorpc_mem_attr attr;      /**< Homing and locality hint bits. */
 386  }
 387  hv;                           /**< Buffer parameters for HV driver. */
 388};
 389
 390
 391/** A structure used to describe interrupts.  The format differs slightly
 392 *  for user and kernel interrupts.  As with the mem_buffer_t, translation
 393 *  between the formats is done at each level. */
 394union iorpc_interrupt
 395{
 396  struct
 397  {
 398    int cpu;   /**< CPU. */
 399    int event; /**< evt_num */
 400  }
 401  user;        /**< Interrupt as described by user applications. */
 402
 403  struct
 404  {
 405    int x;     /**< X coord. */
 406    int y;     /**< Y coord. */
 407    int ipi;   /**< int_num */
 408    int event; /**< evt_num */
 409  }
 410  kernel;      /**< Interrupt as described by the kernel. */
 411
 412};
 413
 414
 415/** A structure used to describe interrupts used with poll().  The format
 416 *  differs significantly for requests from user to kernel, and kernel to
 417 *  hypervisor.  As with the mem_buffer_t, translation between the formats
 418 *  is done at each level. */
 419union iorpc_pollfd_setup
 420{
 421  struct
 422  {
 423    int fd;    /**< Pollable file descriptor. */
 424  }
 425  user;        /**< pollfd_setup as described by user applications. */
 426
 427  struct
 428  {
 429    int x;     /**< X coord. */
 430    int y;     /**< Y coord. */
 431    int ipi;   /**< int_num */
 432    int event; /**< evt_num */
 433  }
 434  kernel;      /**< pollfd_setup as described by the kernel. */
 435
 436};
 437
 438
 439/** A structure used to describe previously set up interrupts used with
 440 *  poll().  The format differs significantly for requests from user to
 441 *  kernel, and kernel to hypervisor.  As with the mem_buffer_t, translation
 442 *  between the formats is done at each level. */
 443union iorpc_pollfd
 444{
 445  struct
 446  {
 447    int fd;    /**< Pollable file descriptor. */
 448  }
 449  user;        /**< pollfd as described by user applications. */
 450
 451  struct
 452  {
 453    int cookie; /**< hv cookie returned by the pollfd_setup operation. */
 454  }
 455  kernel;      /**< pollfd as described by the kernel. */
 456
 457};
 458
 459
 460/** The various iorpc devices use error codes from -1100 to -1299.
 461 *
 462 * This range is distinct from netio (-700 to -799), the hypervisor
 463 * (-800 to -899), tilepci (-900 to -999), ilib (-1000 to -1099),
 464 * gxcr (-1300 to -1399) and gxpci (-1400 to -1499).
 465 */
 466enum gxio_err_e {
 467
 468  /** Largest iorpc error number. */
 469  GXIO_ERR_MAX = -1101,
 470
 471
 472  /********************************************************/
 473  /*                   Generic Error Codes                */
 474  /********************************************************/
 475
 476  /** Bad RPC opcode - possible version incompatibility. */
 477  GXIO_ERR_OPCODE = -1101,
 478
 479  /** Invalid parameter. */
 480  GXIO_ERR_INVAL = -1102,
 481
 482  /** Memory buffer did not meet alignment requirements. */
 483  GXIO_ERR_ALIGNMENT = -1103,
 484
 485  /** Memory buffers must be coherent and cacheable. */
 486  GXIO_ERR_COHERENCE = -1104,
 487
 488  /** Resource already initialized. */
 489  GXIO_ERR_ALREADY_INIT = -1105,
 490
 491  /** No service domains available. */
 492  GXIO_ERR_NO_SVC_DOM = -1106,
 493
 494  /** Illegal service domain number. */
 495  GXIO_ERR_INVAL_SVC_DOM = -1107,
 496
 497  /** Illegal MMIO address. */
 498  GXIO_ERR_MMIO_ADDRESS = -1108,
 499
 500  /** Illegal interrupt binding. */
 501  GXIO_ERR_INTERRUPT = -1109,
 502
 503  /** Unreasonable client memory. */
 504  GXIO_ERR_CLIENT_MEMORY = -1110,
 505
 506  /** No more IOTLB entries. */
 507  GXIO_ERR_IOTLB_ENTRY = -1111,
 508
 509  /** Invalid memory size. */
 510  GXIO_ERR_INVAL_MEMORY_SIZE = -1112,
 511
 512  /** Unsupported operation. */
 513  GXIO_ERR_UNSUPPORTED_OP = -1113,
 514
 515  /** Insufficient DMA credits. */
 516  GXIO_ERR_DMA_CREDITS = -1114,
 517
 518  /** Operation timed out. */
 519  GXIO_ERR_TIMEOUT = -1115,
 520
 521  /** No such device or object. */
 522  GXIO_ERR_NO_DEVICE = -1116,
 523
 524  /** Device or resource busy. */
 525  GXIO_ERR_BUSY = -1117,
 526
 527  /** I/O error. */
 528  GXIO_ERR_IO = -1118,
 529
 530  /** Permissions error. */
 531  GXIO_ERR_PERM = -1119,
 532
 533
 534
 535  /********************************************************/
 536  /*                 Test Device Error Codes              */
 537  /********************************************************/
 538
 539  /** Illegal register number. */
 540  GXIO_TEST_ERR_REG_NUMBER = -1120,
 541
 542  /** Illegal buffer slot. */
 543  GXIO_TEST_ERR_BUFFER_SLOT = -1121,
 544
 545
 546  /********************************************************/
 547  /*                    MPIPE Error Codes                 */
 548  /********************************************************/
 549
 550
 551  /** Invalid buffer size. */
 552  GXIO_MPIPE_ERR_INVAL_BUFFER_SIZE = -1131,
 553
 554  /** Cannot allocate buffer stack. */
 555  GXIO_MPIPE_ERR_NO_BUFFER_STACK = -1140,
 556
 557  /** Invalid buffer stack number. */
 558  GXIO_MPIPE_ERR_BAD_BUFFER_STACK = -1141,
 559
 560  /** Cannot allocate NotifRing. */
 561  GXIO_MPIPE_ERR_NO_NOTIF_RING = -1142,
 562
 563  /** Invalid NotifRing number. */
 564  GXIO_MPIPE_ERR_BAD_NOTIF_RING = -1143,
 565
 566  /** Cannot allocate NotifGroup. */
 567  GXIO_MPIPE_ERR_NO_NOTIF_GROUP = -1144,
 568
 569  /** Invalid NotifGroup number. */
 570  GXIO_MPIPE_ERR_BAD_NOTIF_GROUP = -1145,
 571
 572  /** Cannot allocate bucket. */
 573  GXIO_MPIPE_ERR_NO_BUCKET = -1146,
 574
 575  /** Invalid bucket number. */
 576  GXIO_MPIPE_ERR_BAD_BUCKET = -1147,
 577
 578  /** Cannot allocate eDMA ring. */
 579  GXIO_MPIPE_ERR_NO_EDMA_RING = -1148,
 580
 581  /** Invalid eDMA ring number. */
 582  GXIO_MPIPE_ERR_BAD_EDMA_RING = -1149,
 583
 584  /** Invalid channel number. */
 585  GXIO_MPIPE_ERR_BAD_CHANNEL = -1150,
 586
 587  /** Bad configuration. */
 588  GXIO_MPIPE_ERR_BAD_CONFIG = -1151,
 589
 590  /** Empty iqueue. */
 591  GXIO_MPIPE_ERR_IQUEUE_EMPTY = -1152,
 592
 593  /** Empty rules. */
 594  GXIO_MPIPE_ERR_RULES_EMPTY = -1160,
 595
 596  /** Full rules. */
 597  GXIO_MPIPE_ERR_RULES_FULL = -1161,
 598
 599  /** Corrupt rules. */
 600  GXIO_MPIPE_ERR_RULES_CORRUPT = -1162,
 601
 602  /** Invalid rules. */
 603  GXIO_MPIPE_ERR_RULES_INVALID = -1163,
 604
 605  /** Classifier is too big. */
 606  GXIO_MPIPE_ERR_CLASSIFIER_TOO_BIG = -1170,
 607
 608  /** Classifier is too complex. */
 609  GXIO_MPIPE_ERR_CLASSIFIER_TOO_COMPLEX = -1171,
 610
 611  /** Classifier has bad header. */
 612  GXIO_MPIPE_ERR_CLASSIFIER_BAD_HEADER = -1172,
 613
 614  /** Classifier has bad contents. */
 615  GXIO_MPIPE_ERR_CLASSIFIER_BAD_CONTENTS = -1173,
 616
 617  /** Classifier encountered invalid symbol. */
 618  GXIO_MPIPE_ERR_CLASSIFIER_INVAL_SYMBOL = -1174,
 619
 620  /** Classifier encountered invalid bounds. */
 621  GXIO_MPIPE_ERR_CLASSIFIER_INVAL_BOUNDS = -1175,
 622
 623  /** Classifier encountered invalid relocation. */
 624  GXIO_MPIPE_ERR_CLASSIFIER_INVAL_RELOCATION = -1176,
 625
 626  /** Classifier encountered undefined symbol. */
 627  GXIO_MPIPE_ERR_CLASSIFIER_UNDEF_SYMBOL = -1177,
 628
 629
 630  /********************************************************/
 631  /*                    TRIO  Error Codes                 */
 632  /********************************************************/
 633
 634  /** Cannot allocate memory map region. */
 635  GXIO_TRIO_ERR_NO_MEMORY_MAP = -1180,
 636
 637  /** Invalid memory map region number. */
 638  GXIO_TRIO_ERR_BAD_MEMORY_MAP = -1181,
 639
 640  /** Cannot allocate scatter queue. */
 641  GXIO_TRIO_ERR_NO_SCATTER_QUEUE = -1182,
 642
 643  /** Invalid scatter queue number. */
 644  GXIO_TRIO_ERR_BAD_SCATTER_QUEUE = -1183,
 645
 646  /** Cannot allocate push DMA ring. */
 647  GXIO_TRIO_ERR_NO_PUSH_DMA_RING = -1184,
 648
 649  /** Invalid push DMA ring index. */
 650  GXIO_TRIO_ERR_BAD_PUSH_DMA_RING = -1185,
 651
 652  /** Cannot allocate pull DMA ring. */
 653  GXIO_TRIO_ERR_NO_PULL_DMA_RING = -1186,
 654
 655  /** Invalid pull DMA ring index. */
 656  GXIO_TRIO_ERR_BAD_PULL_DMA_RING = -1187,
 657
 658  /** Cannot allocate PIO region. */
 659  GXIO_TRIO_ERR_NO_PIO = -1188,
 660
 661  /** Invalid PIO region index. */
 662  GXIO_TRIO_ERR_BAD_PIO = -1189,
 663
 664  /** Cannot allocate ASID. */
 665  GXIO_TRIO_ERR_NO_ASID = -1190,
 666
 667  /** Invalid ASID. */
 668  GXIO_TRIO_ERR_BAD_ASID = -1191,
 669
 670
 671  /********************************************************/
 672  /*                    MICA Error Codes                  */
 673  /********************************************************/
 674
 675  /** No such accelerator type. */
 676  GXIO_MICA_ERR_BAD_ACCEL_TYPE = -1220,
 677
 678  /** Cannot allocate context. */
 679  GXIO_MICA_ERR_NO_CONTEXT = -1221,
 680
 681  /** PKA command queue is full, can't add another command. */
 682  GXIO_MICA_ERR_PKA_CMD_QUEUE_FULL = -1222,
 683
 684  /** PKA result queue is empty, can't get a result from the queue. */
 685  GXIO_MICA_ERR_PKA_RESULT_QUEUE_EMPTY = -1223,
 686
 687  /********************************************************/
 688  /*                    GPIO Error Codes                  */
 689  /********************************************************/
 690
 691  /** Pin not available.  Either the physical pin does not exist, or
 692   *  it is reserved by the hypervisor for system usage. */
 693  GXIO_GPIO_ERR_PIN_UNAVAILABLE = -1240,
 694
 695  /** Pin busy.  The pin exists, and is available for use via GXIO, but
 696   *  it has been attached by some other process or driver. */
 697  GXIO_GPIO_ERR_PIN_BUSY = -1241,
 698
 699  /** Cannot access unattached pin.  One or more of the pins being
 700   *  manipulated by this call are not attached to the requesting
 701   *  context. */
 702  GXIO_GPIO_ERR_PIN_UNATTACHED = -1242,
 703
 704  /** Invalid I/O mode for pin.  The wiring of the pin in the system
 705   *  is such that the I/O mode or electrical control parameters
 706   *  requested could cause damage. */
 707  GXIO_GPIO_ERR_PIN_INVALID_MODE = -1243,
 708
 709  /** Smallest iorpc error number. */
 710  GXIO_ERR_MIN = -1299
 711};
 712
 713
 714#endif /* !_HV_IORPC_H_ */
 715