提交 · 3bef7e8aab8af2f86c5785761c37e068428c689d · openeuler / qemu

15 12月, 2015 1 次提交

fw_cfg: amend callback behavior spec to once per select · 3bef7e8a

由 Gabriel L. Somlo 提交于 11月 05, 2015

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: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Message-id: 1446733972-1602-3-git-send-email-somlo@cmu.edu
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

3bef7e8a

19 10月, 2015 2 次提交

fw_cfg: Define a static signature to be returned on DMA port reads · 2cc06a88

由 Kevin O'Connor 提交于 10月 08, 2015

Return a static signature ("QEMU CFG") if the guest does a read to the
DMA address io register.
Signed-off-by: NKevin O'Connor <kevin@koconnor.net>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

2cc06a88

Implement fw_cfg DMA interface · a4c0d1de

由 Marc Marí 提交于 10月 08, 2015

Based on the specifications on docs/specs/fw_cfg.txt

This interface is an addon. The old interface can still be used as usual.

Based on Gerd Hoffman's initial implementation.
Signed-off-by: NMarc Marí <markmb@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

a4c0d1de

11 9月, 2015 1 次提交

maint: avoid useless "if (foo) free(foo)" pattern · ef1e1e07

由 Daniel P. Berrange 提交于 8月 26, 2015

The free() and g_free() functions both happily accept
NULL on any platform QEMU builds on. As such putting a
conditional 'if (foo)' check before calls to 'free(foo)'
merely serves to bloat the lines of code.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

ef1e1e07

10 6月, 2015 4 次提交

fw_cfg: prohibit insertion of duplicate fw_cfg file names · 0eb973f9

由 Gabriel L. Somlo 提交于 4月 29, 2015

Exit with an error (instead of simply logging a trace event)
whenever the same fw_cfg file name is added multiple times via
one of the fw_cfg_add_file[_callback]() host-side API calls.
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

0eb973f9

fw_cfg: prevent selector key conflict · 0f9b2141

由 Gabriel L. Somlo 提交于 4月 29, 2015

Enforce a single assignment of data for each distinct selector key.
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

0f9b2141

fw_cfg: remove support for guest-side data writes · 023e3148

由 Gabriel L. Somlo 提交于 4月 29, 2015

From this point forward, any guest-side writes to the fw_cfg
data register will be treated as no-ops. This patch also removes
the unused host-side API function fw_cfg_add_callback(), which
allowed the registration of a callback to be executed each time
the guest completed a full overwrite of a given fw_cfg data item.
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

023e3148

fw_cfg: add fw_cfg_modify_i16 (update) method · 1edd34b6

由 Gabriel L. Somlo 提交于 6月 08, 2015

Allow the ability to modify the value of an existing 16-bit integer
fw_cfg item.
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

1edd34b6

25 3月, 2015 1 次提交

fw_cfg: factor out initialization of FW_CFG_ID (rev. number) · 3a5c76ba

由 Gabriel L. Somlo 提交于 3月 19, 2015

The fw_cfg documentation says this of the revision key (0x0001, FW_CFG_ID):

> A 32-bit little-endian unsigned int, this item is used as an interface
> revision number, and is currently set to 1 by all QEMU architectures
> which expose a fw_cfg device.

arm/virt doesn't.  It could be argued that that's an error in
"hw/arm/virt.c"; on the other hand, all of the other fw_cfg providing
boards set the interface version to 1 manually, despite the device
coming from the same, shared implementation. Therefore, instead of
adding

    fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);

to arm/virt, consolidate all such existing calls in the fw_cfg
initialization code.
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Message-Id: <1426789244-26318-1-git-send-email-somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

3a5c76ba

19 3月, 2015 1 次提交

Fix remaining warnings from Sparse (void return) · e7ae771f

由 Stefan Weil 提交于 3月 08, 2015

Sparse report:

hw/display/vga.c:2000:5: warning: returning void-valued expression
hw/intc/arm_gic.c:707:9: warning: returning void-valued expression
hw/intc/etraxfs_pic.c:138:9: warning: returning void-valued expression
hw/nvram/fw_cfg.c:475:5: warning: returning void-valued expression
hw/timer/a9gtimer.c:124:5: warning: returning void-valued expression
hw/tpm/tpm_tis.c:794:5: warning: returning void-valued expression
hw/usb/hcd-musb.c:558:9: warning: returning void-valued expression
hw/usb/hcd-musb.c:776:13: warning: returning void-valued expression
hw/usb/hcd-musb.c:867:5: warning: returning void-valued expression
hw/usb/hcd-musb.c:932:5: warning: returning void-valued expression
include/qom/cpu.h:584:5: warning: returning void-valued expression
monitor.c:4686:13: warning: returning void-valued expression
monitor.c:4690:13: warning: returning void-valued expression

Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Andreas Färber <afaerber@suse.de>
Cc: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

e7ae771f

16 1月, 2015 1 次提交

fw_cfg: fix endianness in fw_cfg_data_mem_read() / _write() · 36b62ae6

由 Laszlo Ersek 提交于 1月 16, 2015

(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: NLaszlo Ersek <lersek@redhat.com>
Message-id: 1420024880-15416-1-git-send-email-lersek@redhat.com
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

36b62ae6

23 12月, 2014 6 次提交

fw_cfg_mem: expose the "data_width" property with fw_cfg_init_mem_wide() · 6c87e3d5