0a $  "azD  AS3 /* SPDX-License-Identifier: GPL-2.0 */ /****************************************************************************** * blkif.h * * Unified block-device I/O interface for Xen guest OSes. * * Copyright (c) 2003-2004, Keir Fraser */ #ifndef __XEN_PUBLIC_IO_BLKIF_H__ #define __XEN_PUBLIC_IO_BLKIF_H__ #include #include /* * Front->back notifications: When enqueuing a new request, sending a * notification can be made conditional on req_event (i.e., the generic * hold-off mechanism provided by the ring macros). Backends must set * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()). * * Back->front notifications: When enqueuing a new response, sending a * notification can be made conditional on rsp_event (i.e., the generic * hold-off mechanism provided by the ring macros). Frontends must set * rsp_event appropriately (e.g., using RING_FINAL_CHECK_FOR_RESPONSES()). */ typedef uint16_t blkif_vdev_t; typedef uint64_t blkif_sector_t; /* * Multiple hardware queues/rings: * If supported, the backend will write the key "multi-queue-max-queues" to * the directory for that vbd, and set its value to the maximum supported * number of queues. * Frontends that are aware of this feature and wish to use it can write the * key "multi-queue-num-queues" with the number they wish to use, which must be * greater than zero, and no more than the value reported by the backend in * "multi-queue-max-queues". * * For frontends requesting just one queue, the usual event-channel and * ring-ref keys are written as before, simplifying the backend processing * to avoid distinguishing between a frontend that doesn't understand the * multi-queue feature, and one that does, but requested only one queue. * * Frontends requesting two or more queues must not write the toplevel * event-channel and ring-ref keys, instead writing those keys under sub-keys * having the name "queue-N" where N is the integer ID of the queue/ring for * which those keys belong. Queues are indexed from zero. * For example, a frontend with two queues must write the following set of * queue-related keys: * * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2" * /local/domain/1/device/vbd/0/queue-0 = "" * /local/domain/1/device/vbd/0/queue-0/ring-ref = "" * /local/domain/1/device/vbd/0/queue-0/event-channel = "" * /local/domain/1/device/vbd/0/queue-1 = "" * /local/domain/1/device/vbd/0/queue-1/ring-ref = "" * /local/domain/1/device/vbd/0/queue-1/event-channel = "" * * It is also possible to use multiple queues/rings together with * feature multi-page ring buffer. * For example, a frontend requests two queues/rings and the size of each ring * buffer is two pages must write the following set of related keys: * * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2" * /local/domain/1/device/vbd/0/ring-page-order = "1" * /local/domain/1/device/vbd/0/queue-0 = "" * /local/domain/1/device/vbd/0/queue-0/ring-ref0 = "" * /local/domain/1/device/vbd/0/queue-0/ring-ref1 = "" * /local/domain/1/device/vbd/0/queue-0/event-channel = "" * /local/domain/1/device/vbd/0/queue-1 = "" * /local/domain/1/device/vbd/0/queue-1/ring-ref0 = "" * /local/domain/1/device/vbd/0/queue-1/ring-ref1 = "" * /local/domain/1/device/vbd/0/queue-1/event-channel = "" * */ /* * REQUEST CODES. */ #define BLKIF_OP_READ 0 #define BLKIF_OP_WRITE 1 /* * Recognised only if "feature-barrier" is present in backend xenbus info. * The "feature_barrier" node contains a boolean indicating whether barrier * requests are likely to succeed or fail. Either way, a barrier request * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by * the underlying block-device hardware. The boolean simply indicates whether * or not it is worthwhile for the frontend to attempt barrier requests. *