qemu/include/hw/nvram/fw_cfg.h

187 lines
6.7 KiB
C
Raw Normal View History

#ifndef FW_CFG_H
#define FW_CFG_H
#include "exec/hwaddr.h"
#include "hw/nvram/fw_cfg_keys.h"
typedef struct FWCfgFile {
uint32_t size; /* file size */
uint16_t select; /* write this to 0x510 to read it */
uint16_t reserved;
char name[FW_CFG_MAX_FILE_PATH];
} FWCfgFile;
#define FW_CFG_ORDER_OVERRIDE_VGA 70
#define FW_CFG_ORDER_OVERRIDE_NIC 80
#define FW_CFG_ORDER_OVERRIDE_USER 100
#define FW_CFG_ORDER_OVERRIDE_DEVICE 110
void fw_cfg_set_order_override(FWCfgState *fw_cfg, int order);
void fw_cfg_reset_order_override(FWCfgState *fw_cfg);
typedef struct FWCfgFiles {
uint32_t count;
FWCfgFile f[];
} FWCfgFiles;
/* Control as first field allows for different structures selected by this
* field, which might be useful in the future
*/
typedef struct FWCfgDmaAccess {
uint32_t control;
uint32_t length;
uint64_t address;
} QEMU_PACKED FWCfgDmaAccess;
typedef void (*FWCfgReadCallback)(void *opaque);
/**
* fw_cfg_add_bytes:
* @s: fw_cfg device being modified
* @key: selector key value for new fw_cfg item
* @data: pointer to start of item data
* @len: size of item data
*
* Add a new fw_cfg item, available by selecting the given key, as a raw
* "blob" of the given size. The data referenced by the starting pointer
* is only linked, NOT copied, into the data structure of the fw_cfg device.
*/
void fw_cfg_add_bytes(FWCfgState *s, uint16_t key, void *data, size_t len);
/**
* fw_cfg_add_string:
* @s: fw_cfg device being modified
* @key: selector key value for new fw_cfg item
* @value: NUL-terminated ascii string
*
* Add a new fw_cfg item, available by selecting the given key. The item
* data will consist of a dynamically allocated copy of the provided string,
* including its NUL terminator.
*/
void fw_cfg_add_string(FWCfgState *s, uint16_t key, const char *value);
/**
* fw_cfg_add_i16:
* @s: fw_cfg device being modified
* @key: selector key value for new fw_cfg item
* @value: 16-bit integer
*
* Add a new fw_cfg item, available by selecting the given key. The item
* data will consist of a dynamically allocated copy of the given 16-bit
* value, converted to little-endian representation.
*/
void fw_cfg_add_i16(FWCfgState *s, uint16_t key, uint16_t value);
/**
* fw_cfg_modify_i16:
* @s: fw_cfg device being modified
* @key: selector key value for new fw_cfg item
* @value: 16-bit integer
*
* Replace the fw_cfg item available by selecting the given key. The new
* data will consist of a dynamically allocated copy of the given 16-bit
* value, converted to little-endian representation. The data being replaced,
* assumed to have been dynamically allocated during an earlier call to
* either fw_cfg_add_i16() or fw_cfg_modify_i16(), is freed before returning.
*/
void fw_cfg_modify_i16(FWCfgState *s, uint16_t key, uint16_t value);
/**
* fw_cfg_add_i32:
* @s: fw_cfg device being modified
* @key: selector key value for new fw_cfg item
* @value: 32-bit integer
*
* Add a new fw_cfg item, available by selecting the given key. The item
* data will consist of a dynamically allocated copy of the given 32-bit
* value, converted to little-endian representation.
*/
void fw_cfg_add_i32(FWCfgState *s, uint16_t key, uint32_t value);
/**
* fw_cfg_add_i64:
* @s: fw_cfg device being modified
* @key: selector key value for new fw_cfg item
* @value: 64-bit integer
*
* Add a new fw_cfg item, available by selecting the given key. The item
* data will consist of a dynamically allocated copy of the given 64-bit
* value, converted to little-endian representation.
*/
void fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t value);
/**
* fw_cfg_add_file:
* @s: fw_cfg device being modified
* @filename: name of new fw_cfg file item
* @data: pointer to start of item data
* @len: size of item data
*
* Add a new NAMED fw_cfg item as a raw "blob" of the given size. The data
* referenced by the starting pointer is only linked, NOT copied, into the
* data structure of the fw_cfg device.
* The next available (unused) selector key starting at FW_CFG_FILE_FIRST
* will be used; also, a new entry will be added to the file directory
* structure residing at key value FW_CFG_FILE_DIR, containing the item name,
* data size, and assigned selector key value.
*/
void fw_cfg_add_file(FWCfgState *s, const char *filename, void *data,
size_t len);
/**
* fw_cfg_add_file_callback:
* @s: fw_cfg device being modified
* @filename: name of new fw_cfg file item
* @callback: callback function
* @callback_opaque: argument to be passed into callback function
* @data: pointer to start of item data
* @len: size of item data
*
* Add a new NAMED fw_cfg item as a raw "blob" of the given size. The data
* referenced by the starting pointer is only linked, NOT copied, into the
* data structure of the fw_cfg device.
* The next available (unused) selector key starting at FW_CFG_FILE_FIRST
* will be used; also, a new entry will be added to the file directory
* structure residing at key value FW_CFG_FILE_DIR, containing the item name,
* data size, and assigned selector key value.
* Additionally, set a callback function (and argument) to be called each
fw_cfg: amend callback behavior spec to once per select Currently, the fw_cfg internal API specifies that if an item was set up with a read callback, the callback must be run each time a byte is read from the item. This behavior is both wasteful (most items do not have a read callback set), and impractical for bulk transfers (e.g., DMA read). At the time of this writing, the only items configured with a callback are "/etc/table-loader", "/etc/acpi/tables", and "/etc/acpi/rsdp". They all share the same callback functions: virt_acpi_build_update() on ARM (in hw/arm/virt-acpi-build.c), and acpi_build_update() on i386 (in hw/i386/acpi.c). Both of these callbacks are one-shot (i.e. they return without doing anything at all after the first time they are invoked with a given build_state; since build_state is also shared across all three items mentioned above, the callback only ever runs *once*, the first time either of the listed items is read). This patch amends the specification for fw_cfg_add_file_callback() to state that any available read callback will only be invoked once each time the item is selected. This change has no practical effect on the current behavior of QEMU, and it enables us to significantly optimize the behavior of fw_cfg reads during guest firmware setup, eliminating a large amount of redundant callback checks and invocations. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Marc Marí <markmb@redhat.com> Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1446733972-1602-3-git-send-email-somlo@cmu.edu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-11-05 17:32:48 +03:00
* time this item is selected (by having its selector key either written to
* the fw_cfg control register, or passed to QEMU in FWCfgDmaAccess.control
* with FW_CFG_DMA_CTL_SELECT).
*/
void fw_cfg_add_file_callback(FWCfgState *s, const char *filename,
FWCfgReadCallback callback, void *callback_opaque,
void *data, size_t len);
/**
* fw_cfg_modify_file:
* @s: fw_cfg device being modified
* @filename: name of new fw_cfg file item
* @data: pointer to start of item data
* @len: size of item data
*
* Replace a NAMED fw_cfg item. If an existing item is found, its callback
* information will be cleared, and a pointer to its data will be returned
* to the caller, so that it may be freed if necessary. If an existing item
* is not found, this call defaults to fw_cfg_add_file(), and NULL is
* returned to the caller.
* In either case, the new item data is only linked, NOT copied, into the
* data structure of the fw_cfg device.
*
* Returns: pointer to old item's data, or NULL if old item does not exist.
*/
void *fw_cfg_modify_file(FWCfgState *s, const char *filename, void *data,
size_t len);
FWCfgState *fw_cfg_init_io_dma(uint32_t iobase, uint32_t dma_iobase,
AddressSpace *dma_as);
fw_cfg: hard separation between the MMIO and I/O port mappings We are going to introduce a wide data register for fw_cfg, but only for the MMIO mapped device. The wide data register will also require the tightening of endiannesses. However we don't want to touch the I/O port mapped fw_cfg device at all. Currently QEMU provides a single fw_cfg device type that can handle both I/O port and MMIO mapping. This flexibility is not actually exploited by any board in the tree, but it renders restricting the above changes to MMIO very hard. Therefore, let's derive two classes from TYPE_FW_CFG: TYPE_FW_CFG_IO and TYPE_FW_CFG_MEM. TYPE_FW_CFG_IO incorporates the base I/O port and the related combined MemoryRegion. (NB: all boards in the tree that use the I/O port mapped flavor opt for the combined mapping; that is, when the data port overlays the high address byte of the selector port. Therefore we can drop the capability to map those I/O ports separately.) TYPE_FW_CFG_MEM incorporates the base addresses for the MMIO selector and data registers, and their respective MemoryRegions. The "realize" and "props" class members are specific to each new derived class, and become unused for the base class. The base class retains the "reset" member and the "vmsd" member, because the reset functionality and the set of migrated data are not specific to the mapping. The new functions fw_cfg_init_io() and fw_cfg_init_mem() expose the possible mappings in separation. For now fw_cfg_init() is retained as a compatibility shim that enforces the above assumptions. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 1419250305-31062-2-git-send-email-pbonzini@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2014-12-22 15:11:35 +03:00
FWCfgState *fw_cfg_init_io(uint32_t iobase);
FWCfgState *fw_cfg_init_mem(hwaddr ctl_addr, hwaddr data_addr);
FWCfgState *fw_cfg_init_mem_wide(hwaddr ctl_addr,
hwaddr data_addr, uint32_t data_width,
hwaddr dma_addr, AddressSpace *dma_as);
FWCfgState *fw_cfg_find(void);
#endif