qemu-e2k/hw/nvram/fw_cfg.c

984 lines
28 KiB
C
Raw Normal View History

/*
* QEMU Firmware configuration device emulation
*
* Copyright (c) 2008 Gleb Natapov
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include "qemu/osdep.h"
#include "hw/hw.h"
#include "sysemu/sysemu.h"
#include "sysemu/dma.h"
#include "hw/isa/isa.h"
#include "hw/nvram/fw_cfg.h"
#include "hw/sysbus.h"
#include "trace.h"
#include "qemu/error-report.h"
#include "qemu/config-file.h"
#define FW_CFG_NAME "fw_cfg"
#define FW_CFG_PATH "/machine/" FW_CFG_NAME
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 13:11:35 +01:00
#define TYPE_FW_CFG "fw_cfg"
#define TYPE_FW_CFG_IO "fw_cfg_io"
#define TYPE_FW_CFG_MEM "fw_cfg_mem"
#define FW_CFG(obj) OBJECT_CHECK(FWCfgState, (obj), TYPE_FW_CFG)
#define FW_CFG_IO(obj) OBJECT_CHECK(FWCfgIoState, (obj), TYPE_FW_CFG_IO)
#define FW_CFG_MEM(obj) OBJECT_CHECK(FWCfgMemState, (obj), TYPE_FW_CFG_MEM)
/* FW_CFG_VERSION bits */
#define FW_CFG_VERSION 0x01
#define FW_CFG_VERSION_DMA 0x02
/* FW_CFG_DMA_CONTROL bits */
#define FW_CFG_DMA_CTL_ERROR 0x01
#define FW_CFG_DMA_CTL_READ 0x02
#define FW_CFG_DMA_CTL_SKIP 0x04
#define FW_CFG_DMA_CTL_SELECT 0x08
#define FW_CFG_DMA_SIGNATURE 0x51454d5520434647ULL /* "QEMU CFG" */
typedef struct FWCfgEntry {
uint32_t len;
uint8_t *data;
void *callback_opaque;
FWCfgReadCallback read_callback;
} FWCfgEntry;
struct FWCfgState {
/*< private >*/
SysBusDevice parent_obj;
/*< public >*/
FWCfgEntry entries[2][FW_CFG_MAX_ENTRY];
FWCfgFiles *files;
uint16_t cur_entry;
uint32_t cur_offset;
Notifier machine_ready;
bool dma_enabled;
dma_addr_t dma_addr;
AddressSpace *dma_as;
MemoryRegion dma_iomem;
};
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 13:11:35 +01:00
struct FWCfgIoState {
/*< private >*/
FWCfgState parent_obj;
/*< public >*/
MemoryRegion comb_iomem;
uint32_t iobase, dma_iobase;
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 13:11:35 +01:00
};
struct FWCfgMemState {
/*< private >*/
FWCfgState parent_obj;
/*< public >*/
MemoryRegion ctl_iomem, data_iomem;
uint32_t data_width;
MemoryRegionOps wide_data_ops;
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 13:11:35 +01:00
};
#define JPG_FILE 0
#define BMP_FILE 1
static char *read_splashfile(char *filename, gsize *file_sizep,
int *file_typep)
{
GError *err = NULL;
gboolean res;
gchar *content;
int file_type;
unsigned int filehead;
int bmp_bpp;
res = g_file_get_contents(filename, &content, file_sizep, &err);
if (res == FALSE) {
error_report("failed to read splash file '%s'", filename);
g_error_free(err);
return NULL;
}
/* check file size */
if (*file_sizep < 30) {
goto error;
}
/* check magic ID */
filehead = ((content[0] & 0xff) + (content[1] << 8)) & 0xffff;
if (filehead == 0xd8ff) {
file_type = JPG_FILE;
} else if (filehead == 0x4d42) {
file_type = BMP_FILE;
} else {
goto error;
}
/* check BMP bpp */
if (file_type == BMP_FILE) {
bmp_bpp = (content[28] + (content[29] << 8)) & 0xffff;
if (bmp_bpp != 24) {
goto error;
}
}
/* return values */
*file_typep = file_type;
return content;
error:
error_report("splash file '%s' format not recognized; must be JPEG "
"or 24 bit BMP", filename);
g_free(content);
return NULL;
}
static void fw_cfg_bootsplash(FWCfgState *s)
{
int boot_splash_time = -1;
const char *boot_splash_filename = NULL;
char *p;
char *filename, *file_data;
gsize file_size;
int file_type;
const char *temp;
/* get user configuration */
QemuOptsList *plist = qemu_find_opts("boot-opts");
QemuOpts *opts = QTAILQ_FIRST(&plist->head);
if (opts != NULL) {
temp = qemu_opt_get(opts, "splash");
if (temp != NULL) {
boot_splash_filename = temp;
}
temp = qemu_opt_get(opts, "splash-time");
if (temp != NULL) {
p = (char *)temp;
boot_splash_time = strtol(p, (char **)&p, 10);
}
}
/* insert splash time if user configurated */
if (boot_splash_time >= 0) {
/* validate the input */
if (boot_splash_time > 0xffff) {
error_report("splash time is big than 65535, force it to 65535.");
boot_splash_time = 0xffff;
}
/* use little endian format */
qemu_extra_params_fw[0] = (uint8_t)(boot_splash_time & 0xff);
qemu_extra_params_fw[1] = (uint8_t)((boot_splash_time >> 8) & 0xff);
fw_cfg_add_file(s, "etc/boot-menu-wait", qemu_extra_params_fw, 2);
}
/* insert splash file if user configurated */
if (boot_splash_filename != NULL) {
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, boot_splash_filename);
if (filename == NULL) {
error_report("failed to find file '%s'.", boot_splash_filename);
return;
}
/* loading file data */
file_data = read_splashfile(filename, &file_size, &file_type);
if (file_data == NULL) {
g_free(filename);
return;
}
g_free(boot_splash_filedata);
boot_splash_filedata = (uint8_t *)file_data;
boot_splash_filedata_size = file_size;
/* insert data */
if (file_type == JPG_FILE) {
fw_cfg_add_file(s, "bootsplash.jpg",
boot_splash_filedata, boot_splash_filedata_size);
} else {
fw_cfg_add_file(s, "bootsplash.bmp",
boot_splash_filedata, boot_splash_filedata_size);
}
g_free(filename);
}
}
static void fw_cfg_reboot(FWCfgState *s)
{
int reboot_timeout = -1;
char *p;
const char *temp;
/* get user configuration */
QemuOptsList *plist = qemu_find_opts("boot-opts");
QemuOpts *opts = QTAILQ_FIRST(&plist->head);
if (opts != NULL) {
temp = qemu_opt_get(opts, "reboot-timeout");
if (temp != NULL) {
p = (char *)temp;
reboot_timeout = strtol(p, (char **)&p, 10);
}
}
/* validate the input */
if (reboot_timeout > 0xffff) {
error_report("reboot timeout is larger than 65535, force it to 65535.");
reboot_timeout = 0xffff;
}
fw_cfg_add_file(s, "etc/boot-fail-wait", g_memdup(&reboot_timeout, 4), 4);
}
static void fw_cfg_write(FWCfgState *s, uint8_t value)
{
/* nothing, write support removed in QEMU v2.4+ */
}
static int fw_cfg_select(FWCfgState *s, uint16_t key)
{
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 15:32:48 +01:00
int arch, ret;
FWCfgEntry *e;
s->cur_offset = 0;
if ((key & FW_CFG_ENTRY_MASK) >= FW_CFG_MAX_ENTRY) {
s->cur_entry = FW_CFG_INVALID;
ret = 0;
} else {
s->cur_entry = key;
ret = 1;
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 15:32:48 +01:00
/* entry successfully selected, now run callback if present */
arch = !!(key & FW_CFG_ARCH_LOCAL);
e = &s->entries[arch][key & FW_CFG_ENTRY_MASK];
if (e->read_callback) {
e->read_callback(e->callback_opaque);
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 15:32:48 +01:00
}
}
trace_fw_cfg_select(s, key, ret);
return ret;
}
static uint64_t fw_cfg_data_read(void *opaque, hwaddr addr, unsigned size)
{
FWCfgState *s = opaque;
int arch = !!(s->cur_entry & FW_CFG_ARCH_LOCAL);
FWCfgEntry *e = (s->cur_entry == FW_CFG_INVALID) ? NULL :
&s->entries[arch][s->cur_entry & FW_CFG_ENTRY_MASK];
uint64_t value = 0;
assert(size > 0 && size <= sizeof(value));
if (s->cur_entry != FW_CFG_INVALID && e->data && s->cur_offset < e->len) {
/* The least significant 'size' bytes of the return value are
* expected to contain a string preserving portion of the item
* data, padded with zeros on the right in case we run out early.
* In technical terms, we're composing the host-endian representation
* of the big endian interpretation of the fw_cfg string.
*/
do {
value = (value << 8) | e->data[s->cur_offset++];
} while (--size && s->cur_offset < e->len);
/* If size is still not zero, we *did* run out early, so continue
* left-shifting, to add the appropriate number of padding zeros
* on the right.
*/
value <<= 8 * size;
}
trace_fw_cfg_read(s, value);
return value;
}
static void fw_cfg_data_mem_write(void *opaque, hwaddr addr,
uint64_t value, unsigned size)
{
FWCfgState *s = opaque;
fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write() (1) Let's contemplate what device endianness means, for a memory mapped device register (independently of QEMU -- that is, on physical hardware). It determines the byte order that the device will put on the data bus when the device is producing a *numerical value* for the CPU. This byte order may differ from the CPU's own byte order, therefore when software wants to consume the *numerical value*, it may have to swap the byte order first. For example, suppose we have a device that exposes in a 2-byte register the number of sheep we have to count before falling asleep. If the value is decimal 37 (0x0025), then a big endian register will produce [0x00, 0x25], while a little endian register will produce [0x25, 0x00]. If the device register is big endian, but the CPU is little endian, the numerical value will read as 0x2500 (decimal 9472), which software has to byte swap before use. However... if we ask the device about who stole our herd of sheep, and it answers "XY", then the byte representation coming out of the register must be [0x58, 0x59], regardless of the device register's endianness for numeric values. And, software needs to copy these bytes into a string field regardless of the CPU's own endianness. (2) QEMU's device register accessor functions work with *numerical values* exclusively, not strings: The emulated register's read accessor function returns the numerical value (eg. 37 decimal, 0x0025) as a *host-encoded* uint64_t. QEMU translates this value for the guest to the endianness of the emulated device register (which is recorded in MemoryRegionOps.endianness). Then guest code must translate the numerical value from device register to guest CPU endianness, before including it in any computation (see (1)). (3) However, the data register of the fw_cfg device shall transfer strings *only* -- that is, opaque blobs. Interpretation of any given blob is subject to further agreement -- it can be an integer in an independently determined byte order, or a genuine string, or an array of structs of integers (in some byte order) and fixed size strings, and so on. Because register emulation in QEMU is integer-preserving, not string-preserving (see (2)), we have to jump through a few hoops. (3a) We defined the memory mapped fw_cfg data register as DEVICE_BIG_ENDIAN. The particular choice is not really relevant -- we picked BE only for consistency with the control register, which *does* transfer integers -- but our choice affects how we must host-encode values from fw_cfg strings. (3b) Since we want the fw_cfg string "XY" to appear as the [0x58, 0x59] array on the data register, *and* we picked DEVICE_BIG_ENDIAN, we must compose the host (== C language) value 0x5859 in the read accessor function. (3c) When the guest performs the read access, the immediate uint16_t value will be 0x5958 (in LE guests) and 0x5859 (in BE guests). However, the uint16_t value does not matter. The only thing that matters is the byte pattern [0x58, 0x59], which the guest code must copy into the target string *without* any byte-swapping. (4) Now I get to explain where I screwed up. :( When we decided for big endian *integer* representation in the MMIO data register -- see (3a) --, I mindlessly added an indiscriminate byte-swizzling step to the (little endian) guest firmware. This was a grave error -- it violates (3c) --, but I didn't realize it. I only saw that the code I otherwise intended for fw_cfg_data_mem_read(): value = 0; for (i = 0; i < size; ++i) { value = (value << 8) | fw_cfg_read(s); } didn't produce the expected result in the guest. In true facepalm style, instead of blaming my guest code (which violated (3c)), I blamed my host code (which was correct). Ultimately, I coded ldX_he_p() into fw_cfg_data_mem_read(), because that happened to work. Obviously (...in retrospect) that was wrong. Only because my host happened to be LE, ldX_he_p() composed the (otherwise incorrect) host value 0x5958 from the fw_cfg string "XY". And that happened to compensate for the bogus indiscriminate byte-swizzling in my guest code. Clearly the current code leaks the host endianness through to the guest, which is wrong. Any device should work the same regardless of host endianness. The solution is to compose the host-endian representation (2) of the big endian interpretation (3a, 3b) of the fw_cfg string, and to drop the wrong byte-swizzling in the guest (3c). Brown paper bag time for me. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1420024880-15416-1-git-send-email-lersek@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-01-16 12:54:30 +01:00
unsigned i = size;
fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write() (1) Let's contemplate what device endianness means, for a memory mapped device register (independently of QEMU -- that is, on physical hardware). It determines the byte order that the device will put on the data bus when the device is producing a *numerical value* for the CPU. This byte order may differ from the CPU's own byte order, therefore when software wants to consume the *numerical value*, it may have to swap the byte order first. For example, suppose we have a device that exposes in a 2-byte register the number of sheep we have to count before falling asleep. If the value is decimal 37 (0x0025), then a big endian register will produce [0x00, 0x25], while a little endian register will produce [0x25, 0x00]. If the device register is big endian, but the CPU is little endian, the numerical value will read as 0x2500 (decimal 9472), which software has to byte swap before use. However... if we ask the device about who stole our herd of sheep, and it answers "XY", then the byte representation coming out of the register must be [0x58, 0x59], regardless of the device register's endianness for numeric values. And, software needs to copy these bytes into a string field regardless of the CPU's own endianness. (2) QEMU's device register accessor functions work with *numerical values* exclusively, not strings: The emulated register's read accessor function returns the numerical value (eg. 37 decimal, 0x0025) as a *host-encoded* uint64_t. QEMU translates this value for the guest to the endianness of the emulated device register (which is recorded in MemoryRegionOps.endianness). Then guest code must translate the numerical value from device register to guest CPU endianness, before including it in any computation (see (1)). (3) However, the data register of the fw_cfg device shall transfer strings *only* -- that is, opaque blobs. Interpretation of any given blob is subject to further agreement -- it can be an integer in an independently determined byte order, or a genuine string, or an array of structs of integers (in some byte order) and fixed size strings, and so on. Because register emulation in QEMU is integer-preserving, not string-preserving (see (2)), we have to jump through a few hoops. (3a) We defined the memory mapped fw_cfg data register as DEVICE_BIG_ENDIAN. The particular choice is not really relevant -- we picked BE only for consistency with the control register, which *does* transfer integers -- but our choice affects how we must host-encode values from fw_cfg strings. (3b) Since we want the fw_cfg string "XY" to appear as the [0x58, 0x59] array on the data register, *and* we picked DEVICE_BIG_ENDIAN, we must compose the host (== C language) value 0x5859 in the read accessor function. (3c) When the guest performs the read access, the immediate uint16_t value will be 0x5958 (in LE guests) and 0x5859 (in BE guests). However, the uint16_t value does not matter. The only thing that matters is the byte pattern [0x58, 0x59], which the guest code must copy into the target string *without* any byte-swapping. (4) Now I get to explain where I screwed up. :( When we decided for big endian *integer* representation in the MMIO data register -- see (3a) --, I mindlessly added an indiscriminate byte-swizzling step to the (little endian) guest firmware. This was a grave error -- it violates (3c) --, but I didn't realize it. I only saw that the code I otherwise intended for fw_cfg_data_mem_read(): value = 0; for (i = 0; i < size; ++i) { value = (value << 8) | fw_cfg_read(s); } didn't produce the expected result in the guest. In true facepalm style, instead of blaming my guest code (which violated (3c)), I blamed my host code (which was correct). Ultimately, I coded ldX_he_p() into fw_cfg_data_mem_read(), because that happened to work. Obviously (...in retrospect) that was wrong. Only because my host happened to be LE, ldX_he_p() composed the (otherwise incorrect) host value 0x5958 from the fw_cfg string "XY". And that happened to compensate for the bogus indiscriminate byte-swizzling in my guest code. Clearly the current code leaks the host endianness through to the guest, which is wrong. Any device should work the same regardless of host endianness. The solution is to compose the host-endian representation (2) of the big endian interpretation (3a, 3b) of the fw_cfg string, and to drop the wrong byte-swizzling in the guest (3c). Brown paper bag time for me. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-id: 1420024880-15416-1-git-send-email-lersek@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-01-16 12:54:30 +01:00
do {
fw_cfg_write(s, value >> (8 * --i));
} while (i);
}
static void fw_cfg_dma_transfer(FWCfgState *s)
{
dma_addr_t len;
FWCfgDmaAccess dma;
int arch;
FWCfgEntry *e;
int read;
dma_addr_t dma_addr;
/* Reset the address before the next access */
dma_addr = s->dma_addr;
s->dma_addr = 0;
if (dma_memory_read(s->dma_as, dma_addr, &dma, sizeof(dma))) {
stl_be_dma(s->dma_as, dma_addr + offsetof(FWCfgDmaAccess, control),
FW_CFG_DMA_CTL_ERROR);
return;
}
dma.address = be64_to_cpu(dma.address);
dma.length = be32_to_cpu(dma.length);
dma.control = be32_to_cpu(dma.control);
if (dma.control & FW_CFG_DMA_CTL_SELECT) {
fw_cfg_select(s, dma.control >> 16);
}
arch = !!(s->cur_entry & FW_CFG_ARCH_LOCAL);
e = (s->cur_entry == FW_CFG_INVALID) ? NULL :
&s->entries[arch][s->cur_entry & FW_CFG_ENTRY_MASK];
if (dma.control & FW_CFG_DMA_CTL_READ) {
read = 1;
} else if (dma.control & FW_CFG_DMA_CTL_SKIP) {
read = 0;
} else {
dma.length = 0;
}
dma.control = 0;
while (dma.length > 0 && !(dma.control & FW_CFG_DMA_CTL_ERROR)) {
if (s->cur_entry == FW_CFG_INVALID || !e->data ||
s->cur_offset >= e->len) {
len = dma.length;
/* If the access is not a read access, it will be a skip access,
* tested before.
*/
if (read) {
if (dma_memory_set(s->dma_as, dma.address, 0, len)) {
dma.control |= FW_CFG_DMA_CTL_ERROR;
}
}
} else {
if (dma.length <= (e->len - s->cur_offset)) {
len = dma.length;
} else {
len = (e->len - s->cur_offset);
}
/* If the access is not a read access, it will be a skip access,
* tested before.
*/
if (read) {
if (dma_memory_write(s->dma_as, dma.address,
&e->data[s->cur_offset], len)) {
dma.control |= FW_CFG_DMA_CTL_ERROR;
}
}
s->cur_offset += len;
}
dma.address += len;
dma.length -= len;
}
stl_be_dma(s->dma_as, dma_addr + offsetof(FWCfgDmaAccess, control),
dma.control);
trace_fw_cfg_read(s, 0);
}
static uint64_t fw_cfg_dma_mem_read(void *opaque, hwaddr addr,
unsigned size)
{
/* Return a signature value (and handle various read sizes) */
return extract64(FW_CFG_DMA_SIGNATURE, (8 - addr - size) * 8, size * 8);
}
static void fw_cfg_dma_mem_write(void *opaque, hwaddr addr,
uint64_t value, unsigned size)
{
FWCfgState *s = opaque;
if (size == 4) {
if (addr == 0) {
/* FWCfgDmaAccess high address */
s->dma_addr = value << 32;
} else if (addr == 4) {
/* FWCfgDmaAccess low address */
s->dma_addr |= value;
fw_cfg_dma_transfer(s);
}
} else if (size == 8 && addr == 0) {
s->dma_addr = value;
fw_cfg_dma_transfer(s);
}
}
static bool fw_cfg_dma_mem_valid(void *opaque, hwaddr addr,
unsigned size, bool is_write)
{
return !is_write || ((size == 4 && (addr == 0 || addr == 4)) ||
(size == 8 && addr == 0));
}
static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr,
unsigned size, bool is_write)
{
return addr == 0;
}
static void fw_cfg_ctl_mem_write(void *opaque, hwaddr addr,
uint64_t value, unsigned size)
{
fw_cfg_select(opaque, (uint16_t)value);
}
static bool fw_cfg_ctl_mem_valid(void *opaque, hwaddr addr,
unsigned size, bool is_write)
{
return is_write && size == 2;
}
static void fw_cfg_comb_write(void *opaque, hwaddr addr,
uint64_t value, unsigned size)
{
switch (size) {
case 1:
fw_cfg_write(opaque, (uint8_t)value);
break;
case 2:
fw_cfg_select(opaque, (uint16_t)value);
break;
}
}
static bool fw_cfg_comb_valid(void *opaque, hwaddr addr,
unsigned size, bool is_write)
{
return (size == 1) || (is_write && size == 2);
}
static const MemoryRegionOps fw_cfg_ctl_mem_ops = {
.write = fw_cfg_ctl_mem_write,
.endianness = DEVICE_BIG_ENDIAN,
.valid.accepts = fw_cfg_ctl_mem_valid,
};
static const MemoryRegionOps fw_cfg_data_mem_ops = {
.read = fw_cfg_data_read,
.write = fw_cfg_data_mem_write,
.endianness = DEVICE_BIG_ENDIAN,
.valid = {
.min_access_size = 1,
.max_access_size = 1,
.accepts = fw_cfg_data_mem_valid,
},
};
static const MemoryRegionOps fw_cfg_comb_mem_ops = {
.read = fw_cfg_data_read,
.write = fw_cfg_comb_write,
.endianness = DEVICE_LITTLE_ENDIAN,
.valid.accepts = fw_cfg_comb_valid,
};
static const MemoryRegionOps fw_cfg_dma_mem_ops = {
.read = fw_cfg_dma_mem_read,
.write = fw_cfg_dma_mem_write,
.endianness = DEVICE_BIG_ENDIAN,
.valid.accepts = fw_cfg_dma_mem_valid,
.valid.max_access_size = 8,
.impl.max_access_size = 8,
};
static void fw_cfg_reset(DeviceState *d)
{
FWCfgState *s = FW_CFG(d);
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 15:32:48 +01:00
/* we never register a read callback for FW_CFG_SIGNATURE */
fw_cfg_select(s, FW_CFG_SIGNATURE);
}
/* Save restore 32 bit int as uint16_t
This is a Big hack, but it is how the old state did it.
Or we broke compatibility in the state, or we can't use struct tm
*/
static int get_uint32_as_uint16(QEMUFile *f, void *pv, size_t size)
{
uint32_t *v = pv;
*v = qemu_get_be16(f);
return 0;
}
static void put_unused(QEMUFile *f, void *pv, size_t size)
{
fprintf(stderr, "uint32_as_uint16 is only used for backward compatibility.\n");
fprintf(stderr, "This functions shouldn't be called.\n");
}
static const VMStateInfo vmstate_hack_uint32_as_uint16 = {
.name = "int32_as_uint16",
.get = get_uint32_as_uint16,
.put = put_unused,
};
#define VMSTATE_UINT16_HACK(_f, _s, _t) \
VMSTATE_SINGLE_TEST(_f, _s, _t, 0, vmstate_hack_uint32_as_uint16, uint32_t)
static bool is_version_1(void *opaque, int version_id)
{
return version_id == 1;
}
static bool fw_cfg_dma_enabled(void *opaque)
{
FWCfgState *s = opaque;
return s->dma_enabled;
}
static const VMStateDescription vmstate_fw_cfg_dma = {
.name = "fw_cfg/dma",
.needed = fw_cfg_dma_enabled,
.fields = (VMStateField[]) {
VMSTATE_UINT64(dma_addr, FWCfgState),
VMSTATE_END_OF_LIST()
},
};
static const VMStateDescription vmstate_fw_cfg = {
.name = "fw_cfg",
.version_id = 2,
.minimum_version_id = 1,
.fields = (VMStateField[]) {
VMSTATE_UINT16(cur_entry, FWCfgState),
VMSTATE_UINT16_HACK(cur_offset, FWCfgState, is_version_1),
VMSTATE_UINT32_V(cur_offset, FWCfgState, 2),
VMSTATE_END_OF_LIST()
},
.subsections = (const VMStateDescription*[]) {
&vmstate_fw_cfg_dma,
NULL,
}
};
static void fw_cfg_add_bytes_read_callback(FWCfgState *s, uint16_t key,
FWCfgReadCallback callback,
void *callback_opaque,
void *data, size_t len)
{
int arch = !!(key & FW_CFG_ARCH_LOCAL);
key &= FW_CFG_ENTRY_MASK;
assert(key < FW_CFG_MAX_ENTRY && len < UINT32_MAX);
assert(s->entries[arch][key].data == NULL); /* avoid key conflict */
s->entries[arch][key].data = data;
s->entries[arch][key].len = (uint32_t)len;
s->entries[arch][key].read_callback = callback;
s->entries[arch][key].callback_opaque = callback_opaque;
}
static void *fw_cfg_modify_bytes_read(FWCfgState *s, uint16_t key,
void *data, size_t len)
{
void *ptr;
int arch = !!(key & FW_CFG_ARCH_LOCAL);
key &= FW_CFG_ENTRY_MASK;
assert(key < FW_CFG_MAX_ENTRY && len < UINT32_MAX);
/* return the old data to the function caller, avoid memory leak */
ptr = s->entries[arch][key].data;
s->entries[arch][key].data = data;
s->entries[arch][key].len = len;
s->entries[arch][key].callback_opaque = NULL;
return ptr;
}
void fw_cfg_add_bytes(FWCfgState *s, uint16_t key, void *data, size_t len)
{
fw_cfg_add_bytes_read_callback(s, key, NULL, NULL, data, len);
}
void fw_cfg_add_string(FWCfgState *s, uint16_t key, const char *value)
{
size_t sz = strlen(value) + 1;
fw_cfg_add_bytes(s, key, g_memdup(value, sz), sz);
}
void fw_cfg_add_i16(FWCfgState *s, uint16_t key, uint16_t value)
{
uint16_t *copy;
copy = g_malloc(sizeof(value));
*copy = cpu_to_le16(value);
fw_cfg_add_bytes(s, key, copy, sizeof(value));
}
void fw_cfg_modify_i16(FWCfgState *s, uint16_t key, uint16_t value)
{
uint16_t *copy, *old;
copy = g_malloc(sizeof(value));
*copy = cpu_to_le16(value);
old = fw_cfg_modify_bytes_read(s, key, copy, sizeof(value));
g_free(old);
}
void fw_cfg_add_i32(FWCfgState *s, uint16_t key, uint32_t value)
{
uint32_t *copy;
copy = g_malloc(sizeof(value));
*copy = cpu_to_le32(value);
fw_cfg_add_bytes(s, key, copy, sizeof(value));
}
void fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t value)
{
uint64_t *copy;
copy = g_malloc(sizeof(value));
*copy = cpu_to_le64(value);
fw_cfg_add_bytes(s, key, copy, sizeof(value));
}
void fw_cfg_add_file_callback(FWCfgState *s, const char *filename,
FWCfgReadCallback callback, void *callback_opaque,
void *data, size_t len)
{
int i, index;
size_t dsize;
if (!s->files) {
dsize = sizeof(uint32_t) + sizeof(FWCfgFile) * FW_CFG_FILE_SLOTS;
s->files = g_malloc0(dsize);
fw_cfg_add_bytes(s, FW_CFG_FILE_DIR, s->files, dsize);
}
index = be32_to_cpu(s->files->count);
assert(index < FW_CFG_FILE_SLOTS);
pstrcpy(s->files->f[index].name, sizeof(s->files->f[index].name),
filename);
for (i = 0; i < index; i++) {
if (strcmp(s->files->f[index].name, s->files->f[i].name) == 0) {
error_report("duplicate fw_cfg file name: %s",
s->files->f[index].name);
exit(1);
}
}
fw_cfg_add_bytes_read_callback(s, FW_CFG_FILE_FIRST + index,
callback, callback_opaque, data, len);
s->files->f[index].size = cpu_to_be32(len);
s->files->f[index].select = cpu_to_be16(FW_CFG_FILE_FIRST + index);
trace_fw_cfg_add_file(s, index, s->files->f[index].name, len);
s->files->count = cpu_to_be32(index+1);
}
void fw_cfg_add_file(FWCfgState *s, const char *filename,
void *data, size_t len)
{
fw_cfg_add_file_callback(s, filename, NULL, NULL, data, len);
}
void *fw_cfg_modify_file(FWCfgState *s, const char *filename,
void *data, size_t len)
{
int i, index;
void *ptr = NULL;
assert(s->files);
index = be32_to_cpu(s->files->count);
assert(index < FW_CFG_FILE_SLOTS);
for (i = 0; i < index; i++) {
if (strcmp(filename, s->files->f[i].name) == 0) {
ptr = fw_cfg_modify_bytes_read(s, FW_CFG_FILE_FIRST + i,
data, len);
s->files->f[i].size = cpu_to_be32(len);
return ptr;
}
}
/* add new one */
fw_cfg_add_file_callback(s, filename, NULL, NULL, data, len);
return NULL;
}
static void fw_cfg_machine_reset(void *opaque)
{
void *ptr;
size_t len;
FWCfgState *s = opaque;
char *bootindex = get_boot_devices_list(&len, false);
ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)bootindex, len);
g_free(ptr);
}
static void fw_cfg_machine_ready(struct Notifier *n, void *data)
{
FWCfgState *s = container_of(n, FWCfgState, machine_ready);
qemu_register_reset(fw_cfg_machine_reset, s);
}
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 13:11:35 +01:00
static void fw_cfg_init1(DeviceState *dev)
{
FWCfgState *s = FW_CFG(dev);
assert(!object_resolve_path(FW_CFG_PATH, NULL));
object_property_add_child(qdev_get_machine(), FW_CFG_NAME, OBJECT(s), NULL);
qdev_init_nofail(dev);
fw_cfg_add_bytes(s, FW_CFG_SIGNATURE, (char *)"QEMU", 4);
fw_cfg_add_bytes(s, FW_CFG_UUID, qemu_uuid, 16);
fw_cfg_add_i16(s, FW_CFG_NOGRAPHIC, (uint16_t)(display_type == DT_NOGRAPHIC));
fw_cfg_add_i16(s, FW_CFG_NB_CPUS, (uint16_t)smp_cpus);
fw_cfg_add_i16(s, FW_CFG_BOOT_MENU, (uint16_t)boot_menu);
fw_cfg_bootsplash(s);
fw_cfg_reboot(s);
s->machine_ready.notify = fw_cfg_machine_ready;
qemu_add_machine_init_done_notifier(&s->machine_ready);
}
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 13:11:35 +01:00
DeviceState *dev;
FWCfgState *s;
uint32_t version = FW_CFG_VERSION;
bool dma_requested = dma_iobase && 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 13:11:35 +01:00
dev = qdev_create(NULL, TYPE_FW_CFG_IO);
qdev_prop_set_uint32(dev, "iobase", iobase);
qdev_prop_set_uint32(dev, "dma_iobase", dma_iobase);
if (!dma_requested) {
qdev_prop_set_bit(dev, "dma_enabled", false);
}
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 13:11:35 +01:00
fw_cfg_init1(dev);
s = FW_CFG(dev);
if (s->dma_enabled) {
/* 64 bits for the address field */
s->dma_as = dma_as;
s->dma_addr = 0;
version |= FW_CFG_VERSION_DMA;
}
fw_cfg_add_i32(s, FW_CFG_ID, version);
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 13:11:35 +01:00
return s;
}
FWCfgState *fw_cfg_init_io(uint32_t iobase)
{
return fw_cfg_init_io_dma(iobase, 0, NULL);
}
FWCfgState *fw_cfg_init_mem_wide(hwaddr ctl_addr,
hwaddr data_addr, uint32_t data_width,
hwaddr dma_addr, 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 13:11:35 +01:00
DeviceState *dev;
SysBusDevice *sbd;
FWCfgState *s;
uint32_t version = FW_CFG_VERSION;
bool dma_requested = dma_addr && 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 13:11:35 +01:00
dev = qdev_create(NULL, TYPE_FW_CFG_MEM);
qdev_prop_set_uint32(dev, "data_width", data_width);
if (!dma_requested) {
qdev_prop_set_bit(dev, "dma_enabled", false);
}
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 13:11:35 +01:00
fw_cfg_init1(dev);
sbd = SYS_BUS_DEVICE(dev);
sysbus_mmio_map(sbd, 0, ctl_addr);
sysbus_mmio_map(sbd, 1, data_addr);
s = FW_CFG(dev);
if (s->dma_enabled) {
s->dma_as = dma_as;
s->dma_addr = 0;
sysbus_mmio_map(sbd, 2, dma_addr);
version |= FW_CFG_VERSION_DMA;
}
fw_cfg_add_i32(s, FW_CFG_ID, version);
return s;
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 13:11:35 +01:00
}
FWCfgState *fw_cfg_init_mem(hwaddr ctl_addr, hwaddr data_addr)
{
return fw_cfg_init_mem_wide(ctl_addr, data_addr,
fw_cfg_data_mem_ops.valid.max_access_size,
0, NULL);
}
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 13:11:35 +01:00
FWCfgState *fw_cfg_find(void)
{
return FW_CFG(object_resolve_path(FW_CFG_PATH, NULL));
}
static void fw_cfg_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
dc->reset = fw_cfg_reset;
dc->vmsd = &vmstate_fw_cfg;
}
static const TypeInfo fw_cfg_info = {
.name = TYPE_FW_CFG,
.parent = TYPE_SYS_BUS_DEVICE,
.instance_size = sizeof(FWCfgState),
.class_init = fw_cfg_class_init,
};
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 13:11:35 +01:00
static Property fw_cfg_io_properties[] = {
DEFINE_PROP_UINT32("iobase", FWCfgIoState, iobase, -1),
DEFINE_PROP_UINT32("dma_iobase", FWCfgIoState, dma_iobase, -1),
DEFINE_PROP_BOOL("dma_enabled", FWCfgIoState, parent_obj.dma_enabled,
true),
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 13:11:35 +01:00
DEFINE_PROP_END_OF_LIST(),
};
static void fw_cfg_io_realize(DeviceState *dev, Error **errp)
{
FWCfgIoState *s = FW_CFG_IO(dev);
SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
/* when using port i/o, the 8-bit data register ALWAYS overlaps
* with half of the 16-bit control register. Hence, the total size
* of the i/o region used is FW_CFG_CTL_SIZE */
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 13:11:35 +01:00
memory_region_init_io(&s->comb_iomem, OBJECT(s), &fw_cfg_comb_mem_ops,
FW_CFG(s), "fwcfg", FW_CFG_CTL_SIZE);
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 13:11:35 +01:00
sysbus_add_io(sbd, s->iobase, &s->comb_iomem);
if (FW_CFG(s)->dma_enabled) {
memory_region_init_io(&FW_CFG(s)->dma_iomem, OBJECT(s),
&fw_cfg_dma_mem_ops, FW_CFG(s), "fwcfg.dma",
sizeof(dma_addr_t));
sysbus_add_io(sbd, s->dma_iobase, &FW_CFG(s)->dma_iomem);
}
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 13:11:35 +01:00
}
static void fw_cfg_io_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
dc->realize = fw_cfg_io_realize;
dc->props = fw_cfg_io_properties;
}
static const TypeInfo fw_cfg_io_info = {
.name = TYPE_FW_CFG_IO,
.parent = TYPE_FW_CFG,
.instance_size = sizeof(FWCfgIoState),
.class_init = fw_cfg_io_class_init,
};
static Property fw_cfg_mem_properties[] = {
DEFINE_PROP_UINT32("data_width", FWCfgMemState, data_width, -1),
DEFINE_PROP_BOOL("dma_enabled", FWCfgMemState, parent_obj.dma_enabled,
true),
DEFINE_PROP_END_OF_LIST(),
};
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 13:11:35 +01:00
static void fw_cfg_mem_realize(DeviceState *dev, Error **errp)
{
FWCfgMemState *s = FW_CFG_MEM(dev);
SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
const MemoryRegionOps *data_ops = &fw_cfg_data_mem_ops;
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 13:11:35 +01:00
memory_region_init_io(&s->ctl_iomem, OBJECT(s), &fw_cfg_ctl_mem_ops,
FW_CFG(s), "fwcfg.ctl", FW_CFG_CTL_SIZE);
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 13:11:35 +01:00
sysbus_init_mmio(sbd, &s->ctl_iomem);
if (s->data_width > data_ops->valid.max_access_size) {
/* memberwise copy because the "old_mmio" member is const */
s->wide_data_ops.read = data_ops->read;
s->wide_data_ops.write = data_ops->write;
s->wide_data_ops.endianness = data_ops->endianness;
s->wide_data_ops.valid = data_ops->valid;
s->wide_data_ops.impl = data_ops->impl;
s->wide_data_ops.valid.max_access_size = s->data_width;
s->wide_data_ops.impl.max_access_size = s->data_width;
data_ops = &s->wide_data_ops;
}
memory_region_init_io(&s->data_iomem, OBJECT(s), data_ops, FW_CFG(s),
"fwcfg.data", data_ops->valid.max_access_size);
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 13:11:35 +01:00
sysbus_init_mmio(sbd, &s->data_iomem);
if (FW_CFG(s)->dma_enabled) {
memory_region_init_io(&FW_CFG(s)->dma_iomem, OBJECT(s),
&fw_cfg_dma_mem_ops, FW_CFG(s), "fwcfg.dma",
sizeof(dma_addr_t));
sysbus_init_mmio(sbd, &FW_CFG(s)->dma_iomem);
}
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 13:11:35 +01:00
}
static void fw_cfg_mem_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
dc->realize = fw_cfg_mem_realize;
dc->props = fw_cfg_mem_properties;
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 13:11:35 +01:00
}
static const TypeInfo fw_cfg_mem_info = {
.name = TYPE_FW_CFG_MEM,
.parent = TYPE_FW_CFG,
.instance_size = sizeof(FWCfgMemState),
.class_init = fw_cfg_mem_class_init,
};
static void fw_cfg_register_types(void)
{
type_register_static(&fw_cfg_info);
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 13:11:35 +01:00
type_register_static(&fw_cfg_io_info);
type_register_static(&fw_cfg_mem_info);
}
type_init(fw_cfg_register_types)