Documentation/arch/sparc/oradax/oracle-dax.rst

Source file repositories/reference/linux-study-clean/Documentation/arch/sparc/oradax/oracle-dax.rst

File Facts

System
Linux kernel
Corpus path
Documentation/arch/sparc/oradax/oracle-dax.rst
Extension
.rst
Size
18696 bytes
Lines
446
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

struct ccb {
       u64   control;
       u64   completion;
       u64   input0;
       u64   access;
       u64   input1;
       u64   op_data;
       u64   output;
       u64   table;
   };

See libdax/common/sys/dax1/dax1_ccb.h for a detailed description of
each of these fields, and see dax-hv-api.txt for a complete description
of the Hypervisor API available to the guest OS (ie, Linux kernel).

The first word (control) is examined by the driver for the following:
 - CCB version, which must be consistent with hardware version
 - Opcode, which must be one of the documented allowable commands
 - Address types, which must be set to "virtual" for all the addresses
   given by the user, thereby ensuring that the application can
   only access memory that it owns


Example Code
============

The DAX is accessible to both user and kernel code.  The kernel code
can make hypercalls directly while the user code must use wrappers
provided by the driver. The setup of the CCB is nearly identical for
both; the only difference is in preparation of the completion area. An
example of user code is given now, with kernel code afterwards.

In order to program using the driver API, the file
arch/sparc/include/uapi/asm/oradax.h must be included.

First, the proper device must be opened. For M7 it will be
/dev/oradax1 and for M8 it will be /dev/oradax2. The simplest
procedure is to attempt to open both, as only one will succeed::

	fd = open("/dev/oradax1", O_RDWR);
	if (fd < 0)
		fd = open("/dev/oradax2", O_RDWR);
	if (fd < 0)
	       /* No DAX found */

Next, the completion area must be mapped::

      completion_area = mmap(NULL, DAX_MMAP_LEN, PROT_READ, MAP_SHARED, fd, 0);

All input and output buffers must be fully contained in one hardware
page, since as explained above, the DAX is strictly constrained by
virtual page boundaries.  In addition, the output buffer must be
64-byte aligned and its size must be a multiple of 64 bytes because
the coprocessor writes in units of cache lines.

This example demonstrates the DAX Scan command, which takes as input a
vector and a match value, and produces a bitmap as the output. For
each input element that matches the value, the corresponding bit is
set in the output.

In this example, the input vector consists of a series of single bits,
and the match value is 0. So each 0 bit in the input will produce a 1
in the output, and vice versa, which produces an output bitmap which
is the input bitmap inverted.

For details of all the parameters and bits used in this CCB, please
refer to section 36.2.1.3 of the DAX Hypervisor API document, which
describes the Scan command in detail::

	ccb->control =       /* Table 36.1, CCB Header Format */

Annotation

Implementation Notes