[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] b28fb2: audio: Don't free hw resources until
|
From: |
GitHub |
|
Subject: |
[Qemu-commits] [qemu/qemu] b28fb2: audio: Don't free hw resources until after hw back... |
|
Date: |
Tue, 23 Dec 2014 10:00:09 -0800 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: b28fb27b5edf77f6fd0ac550a156fb20f2218db3
https://github.com/qemu/qemu/commit/b28fb27b5edf77f6fd0ac550a156fb20f2218db3
Author: Peter Maydell <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M audio/audio_template.h
Log Message:
-----------
audio: Don't free hw resources until after hw backend is stopped
When stopping an audio voice, call the audio backend's fini
method before calling audio_pcm_hw_free_resources_ rather than
afterwards. This allows backends which use helper threads (like
pulseaudio) to terminate those threads before the conv_buf or
mix_buf are freed and avoids race conditions where the helper
may access a NULL pointer or freed memory.
Cc: address@hidden
Reviewed-by: Gerd Hoffmann <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Commit: 60fb1a87b47b14e4ea67043aa56f353e77fbd70a
https://github.com/qemu/qemu/commit/60fb1a87b47b14e4ea67043aa56f353e77fbd70a
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M target-arm/helper.c
Log Message:
-----------
target-arm: Merge EL3 CP15 register lists
Merge of the v8_el2_cp_reginfo and el3_cp_reginfo ARMCPRegInfo lists.
Previously, some EL3 registers were restricted to the ARMv8 list under the
impression that they were not needed on ARMv7. However, this is not the case
as the ARMv7/32-bit variants rely on the ARMv8/64-bit variants to handle
migration and reset. For this reason they must always exist.
Signed-off-by: Greg Bellows <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
https://github.com/qemu/qemu/commit/49d2e648e8087d154d8bf8b91f27c8e05e79d5a6
Author: Marcel Apfelbaum <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/core/machine.c
M hw/i386/pc.c
M hw/ppc/spapr.c
M vl.c
Log Message:
-----------
machine: remove qemu_machine_opts global list
QEMU has support for options per machine, keeping
a global list of options is no longer necessary.
Signed-off-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Alexander Graf <address@hidden>
Reviewed-by: Greg Bellows <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 2e16898a61a25cb76dd48f6e74f3b7a500d0c91a
https://github.com/qemu/qemu/commit/2e16898a61a25cb76dd48f6e74f3b7a500d0c91a
Author: Marcel Apfelbaum <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M vl.c
Log Message:
-----------
vl.c: simplified machine_set_property
Refactored the code to re-use object_property_parse.
Signed-off-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Alexander Graf <address@hidden>
Reviewed-by: Greg Bellows <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 52eb3dfd7d6585f0049a6d41ddb81ef8d4496146
https://github.com/qemu/qemu/commit/52eb3dfd7d6585f0049a6d41ddb81ef8d4496146
Author: Marcel Apfelbaum <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M vl.c
Log Message:
-----------
vl.c: add HMP help to machine
The help is based on the actual machine properties
exposing only the relevant options.
Signed-off-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Alexander Graf <address@hidden>
Reviewed-by: Greg Bellows <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 7eb1dc7f0b65a324323541440baf2ea544adcefb
https://github.com/qemu/qemu/commit/7eb1dc7f0b65a324323541440baf2ea544adcefb
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/vexpress.c
Log Message:
-----------
target-arm: Add vexpress class and machine types
Adds base Vexpress class and machine objects and infrastructure. This is in
preparation for switching to the full QEMU object model. The base vexpress
infrastructure is intended to handle common vexpress details.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 9ee00ba8311a9cc59f8d1034c98b6f9f3694495b
https://github.com/qemu/qemu/commit/9ee00ba8311a9cc59f8d1034c98b6f9f3694495b
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/vexpress.c
Log Message:
-----------
target-arm: Add vexpress a9 & a15 machine objects
Add Vexpress machine objects for the the Cortex A9 & A15 variants. The older
style QEMUMachine types were replaced with dedicated TypeInfo objects. The new
objects include dedicated class init functions that currently ustilze dedicated
machine init methods. The previous qemu_register_machine calls were replaced
with the newer type_register_status calls.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: af7c9f34b1bacd329a479e79bd608580d0511596
https://github.com/qemu/qemu/commit/af7c9f34b1bacd329a479e79bd608580d0511596
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/vexpress.c
Log Message:
-----------
target-arm: Switch to common vexpress machine init
Switched the Vexpress machine initialization to use the common function with
the machine pointer to board info.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 490219243208a0fa8abb2290509f31654c888954
https://github.com/qemu/qemu/commit/490219243208a0fa8abb2290509f31654c888954
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/vexpress.c
Log Message:
-----------
target-arm: Add vexpress machine secure property
Add "secure" Vexpress machine specific property to allow override of the
default secure state configuration. By default, when using the QEMU
-kernel command line argument, Vexpress machines boot into NS/SVC. When using
the QEMU -bios command line argument, Vexpress machines boot into S/SVC.
The secure state can be changed from the default specifying the secure
state as a machine property. For example, the below command line would disable
security extensions on a -kernel Linux boot:
aarch64-softmmu/qemu-system-aarch64
-machine type=vexpress-a15,secure=off
-kernel ...
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: e364bab69bd70825e7583e0bbc812fb67b63b366
https://github.com/qemu/qemu/commit/e364bab69bd70825e7583e0bbc812fb67b63b366
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/vexpress.c
Log Message:
-----------
target-arm: Change vexpress daughterboard init arg
Change the Vexpress daughterboard initialization method to take a vexpress
machine state pointer instead of the daughterboard struct pointer. The machine
state now contains the daughterboard pointer.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: c29196904b2bad015edc553a5693c5c9e6f8177a
https://github.com/qemu/qemu/commit/c29196904b2bad015edc553a5693c5c9e6f8177a
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
target-arm: Add virt class and machine types
Switch virt qemu machine support to use the newer object type, class, and
instance model. Added virt TypeInfo with static registration along with virt
specific class and machine structs. Also added virt class initialization
method.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 083a58906cb32731dd98a93fcf451ec7718c0924
https://github.com/qemu/qemu/commit/083a58906cb32731dd98a93fcf451ec7718c0924
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
target-arm: Add virt machine secure property
Add "secure" virt machine specific property to allow override of the
default secure state configuration. By default, when using the QEMU
-kernel command line argument, virt machines boot into NS/SVC. When using
the QEMU -bios command line argument, virt machines boot into S/SVC.
The secure state can be changed from the default specifying the secure
state as a machine property. For example, the below command line would disable
security extensions on a -kernel Linux boot:
aarch64-softmmu/qemu-system-aarch64
-machine type=virt,secure=off
-kernel ...
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 08828484a5c1ec55a6cbb4b4d377bfcf41199b5c
https://github.com/qemu/qemu/commit/08828484a5c1ec55a6cbb4b4d377bfcf41199b5c
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M target-arm/cpu.c
Log Message:
-----------
target-arm: Add feature unset function
Add an unset_feature() function to compliment the set_feature() function. This
will be used to disable functions after they have been enabled during
initialization.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 51942aee3c51ca23b0dd78f95534a57e8dc1e582
https://github.com/qemu/qemu/commit/51942aee3c51ca23b0dd78f95534a57e8dc1e582
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M target-arm/cpu-qom.h
M target-arm/cpu.c
Log Message:
-----------
target-arm: Add ARMCPU secure property
Added a "has_el3" state property to the ARMCPU descriptor. This property
indicates whether the ARMCPU has security extensions enabled (EL3) or not.
By default it is disabled at this time.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: c8e829b7bf6e1c84af8b4b13ee7fce2959c63e0e
https://github.com/qemu/qemu/commit/c8e829b7bf6e1c84af8b4b13ee7fce2959c63e0e
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/boot.c
M include/hw/arm/arm.h
Log Message:
-----------
target-arm: Add arm_boot_info secure_boot control
Adds the secure_boot boolean field to the arm_boot_info descriptor. This
fields is used to indicate whether Linux should boot into secure or non-secure
state if the ARM EL3 feature is enabled. The default is to leave the CPU in an
unaltered reset state. On EL3 enabled systems, the reset state is secure and
can be overridden by setting the added field to false.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 12d027f132246826c4358f3734d738a3385bf75f
https://github.com/qemu/qemu/commit/12d027f132246826c4358f3734d738a3385bf75f
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/vexpress.c
Log Message:
-----------
target-arm: Enable CPU has_el3 prop during VE init
Adds setting of the CPU has_el3 property based on the vexpress machine
secure state property during initialization. This enables/disables EL3
state during start-up. Changes include adding an additional secure state
boolean during vexpress CPU initialization. Also enables the ARM secure boot
by default.
Signed-off-by: Greg Bellows <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: e5a5604f8fdabfc788fbf75354b7f92eb349dcff
https://github.com/qemu/qemu/commit/e5a5604f8fdabfc788fbf75354b7f92eb349dcff
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
target-arm: Set CPU has_el3 prop during virt init
Adds setting of the CPU has_el3 property based on the virt machine
secure state property during initialization. This enables/disables EL3
state during start-up. Changes include adding an additional secure state
boolean during virt CPU initialization. Also disables the ARM secure boot
by default.
Signed-off-by: Greg Bellows <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Commit: 223a72f1179dc0b56bae3b01bc3e3208ef100fcc
https://github.com/qemu/qemu/commit/223a72f1179dc0b56bae3b01bc3e3208ef100fcc
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/integratorcp.c
M hw/arm/versatilepb.c
Log Message:
-----------
target-arm: Breakout integratorcp and versatilepb cpu init
This commit changes the integratorcp and versatilepb CPU initialization from
using the generic ARM cpu_arm_init function to doing it inline. This is
necessary in order to allow CPU configuration changes to occur between CPU
instance initialization and realization. Specifically, this change is in
preparation for disabling CPU EL3 support.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 61e2f3521c9ee2dc3ebab2e84329d5ebd10d8518
https://github.com/qemu/qemu/commit/61e2f3521c9ee2dc3ebab2e84329d5ebd10d8518
Author: Greg Bellows <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/exynos4210.c
M hw/arm/highbank.c
M hw/arm/integratorcp.c
M hw/arm/realview.c
M hw/arm/versatilepb.c
M hw/arm/xilinx_zynq.c
Log Message:
-----------
target-arm: Disable EL3 on unsupported machines
Disables the CPU ARM_FEATURE_EL3 featuere on machine models that can be
configured to use Cortex-A9, Cortex-A15, and ARM1176 but don't officially
support EL3. This preserves backwards compatibility.
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: c0ccb02db46c72b4b0fa8a475a6890c1e28064f0
https://github.com/qemu/qemu/commit/c0ccb02db46c72b4b0fa8a475a6890c1e28064f0
Author: Fabian Aggeler <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M target-arm/cpu.c
Log Message:
-----------
target-arm: add cpu feature EL3 to CPUs with Security Extensions
Set ARM_FEATURE_EL3 feature for CPUs that implement Security Extensions.
Signed-off-by: Fabian Aggeler <address@hidden>
Signed-off-by: Greg Bellows <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 5712db6ae5101db645f71edc393368cd59bfd314
https://github.com/qemu/qemu/commit/5712db6ae5101db645f71edc393368cd59bfd314
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/nvram/fw_cfg.c
M include/hw/nvram/fw_cfg.h
M include/qemu/typedefs.h
Log Message:
-----------
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 <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 66708822cd3007ae1ec5104d274a861148725e7a
https://github.com/qemu/qemu/commit/66708822cd3007ae1ec5104d274a861148725e7a
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/i386/pc.c
M hw/nvram/fw_cfg.c
M hw/ppc/mac_newworld.c
M hw/ppc/mac_oldworld.c
M hw/sparc/sun4m.c
M hw/sparc64/sun4u.c
M include/hw/nvram/fw_cfg.h
Log Message:
-----------
fw_cfg: move boards to fw_cfg_init_io() / fw_cfg_init_mem()
This allows us to drop the fw_cfg_init() shim and to enforce the possible
mappings at compile time.
Signed-off-by: Laszlo Ersek <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 86099db3823fec1800225f89544014a98b227ed9
https://github.com/qemu/qemu/commit/86099db3823fec1800225f89544014a98b227ed9
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/nvram/fw_cfg.c
Log Message:
-----------
fw_cfg_mem: max access size and region size are the same for data register
Make it clear that the maximum access size to the MMIO data register
determines the full size of the memory region.
Currently the max access size is 1.
This patch doesn't change behavior.
Signed-off-by: Laszlo Ersek <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: d789c84547abaaf82828b20998aee618b9327261
https://github.com/qemu/qemu/commit/d789c84547abaaf82828b20998aee618b9327261
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/nvram/fw_cfg.c
Log Message:
-----------
fw_cfg_mem: flip ctl_mem_ops and data_mem_ops to DEVICE_BIG_ENDIAN
The standalone selector port (fw_cfg_ctl_mem_ops) is only used by big
endian guests to date (*), hence this change doesn't regress them. Paolo
and Alex have suggested / requested an explicit DEVICE_BIG_ENDIAN setting
here, for clarity.
(*) git grep -l fw_cfg_init_mem
hw/nvram/fw_cfg.c
hw/ppc/mac_newworld.c
hw/ppc/mac_oldworld.c
hw/sparc/sun4m.c
include/hw/nvram/fw_cfg.h
The standalone data port (fw_cfg_data_mem_ops) has max_access_size 1 (for
now), hence changing its endianness doesn't change behavior for existing
guest code.
Signed-off-by: Laszlo Ersek <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: ff6cff7554be06e95f8d712f66cd16bd6681c746
https://github.com/qemu/qemu/commit/ff6cff7554be06e95f8d712f66cd16bd6681c746
Author: Paolo Bonzini <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M exec.c
Log Message:
-----------
exec: allows 8-byte accesses in subpage_ops
Otherwise fw_cfg accesses are split into 4-byte ones before they reach the
fw_cfg ops / handlers.
Signed-off-by: Paolo Bonzini <address@hidden>
Signed-off-by: Laszlo Ersek <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: cfaadf0e89e7c2a47462d5f96390c9a9b4de037c
https://github.com/qemu/qemu/commit/cfaadf0e89e7c2a47462d5f96390c9a9b4de037c
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/nvram/fw_cfg.c
Log Message:
-----------
fw_cfg_mem: introduce the "data_width" property
The "data_width" property is capable of changing the maximum valid access
size to the MMIO data register, and resizes the memory region similarly,
at device realization time.
The default value of "data_memwidth" is set so that we don't yet diverge
from "fw_cfg_data_mem_ops".
Most of the fw_cfg_mem users will stick with the default, and for them we
should continue using the statically allocated "fw_cfg_data_mem_ops". This
is beneficial for debugging because gdb can resolve pointers referencing
static objects to the names of those objects.
Signed-off-by: Laszlo Ersek <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 6c87e3d5967a1d731b5f591a8f0ee6c319c14ca8
https://github.com/qemu/qemu/commit/6c87e3d5967a1d731b5f591a8f0ee6c319c14ca8
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/nvram/fw_cfg.c
M include/hw/nvram/fw_cfg.h
Log Message:
-----------
fw_cfg_mem: expose the "data_width" property with fw_cfg_init_mem_wide()
We rebase fw_cfg_init_mem() to the new function for compatibility with
current callers.
The behavior of the (big endian) multi-byte data reads is best shown
with a qtest session. Here, we are reading the first six bytes of
the UUID
$ arm-softmmu/qemu-system-arm -M virt -machine accel=qtest \
-qtest stdio -uuid 4600cb32-38ec-4b2f-8acb-81c6ea54f2d8
>>> writew 0x9020008 0x0200
<<< OK
>>> readl 0x9020000
<<< OK 0x000000004600cb32
Remember this is big endian. On big endian machines, it is stored
directly as 0x46 0x00 0xcb 0x32.
On a little endian machine, we have to first swap it, so that it becomes
0x32cb0046. When written to memory, it becomes 0x46 0x00 0xcb 0x32
again.
Reading byte-by-byte works too, of course:
>>> readb 0x9020000
<<< OK 0x0000000000000038
>>> readb 0x9020000
<<< OK 0x00000000000000ec
Here only a single byte is read at a time, so they are read in order
similar to the 1-byte data port that is already in PPC and SPARC
machines.
Signed-off-by: Laszlo Ersek <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 578f3c7b083514b4fec0bf8fa0617934cdbdf826
https://github.com/qemu/qemu/commit/578f3c7b083514b4fec0bf8fa0617934cdbdf826
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
arm: add fw_cfg to "virt" board
fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
board.
Because MMIO access is slow on ARM KVM, we enable the guest, with
fw_cfg_init_mem_wide(), to transfer up to 8 bytes with a single access.
This has been measured to speed up transfers up to 7.5-fold, relative to
single byte data access, on both ARM KVM and x86_64 TCG.
The MMIO register block of fw_cfg is advertized in the device tree. As
base address we pick 0x09020000, which conforms to the comment preceding
"a15memmap": it falls in the miscellaneous device I/O range 128MB..256MB,
and it is aligned at 64KB. The DTB properties follow the documentation in
the Linux source file "Documentation/devicetree/bindings/arm/fw-cfg.txt".
fw_cfg automatically exports a number of files to the guest; for example,
"bootorder" (see fw_cfg_machine_reset()).
Signed-off-by: Laszlo Ersek <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 7d48a0f7217474899c5f5920b21f4cfdf4efa8d1
https://github.com/qemu/qemu/commit/7d48a0f7217474899c5f5920b21f4cfdf4efa8d1
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/core/loader.c
M include/hw/loader.h
Log Message:
-----------
hw/loader: split out load_image_gzipped_buffer()
In the next patch we'd like to reuse the image decompression facility
without installing the output as a ROM at a specific guest-phys address.
In addition, expose LOAD_IMAGE_MAX_GUNZIP_BYTES, because that's a
straightforward "max_sz" argument for the new load_image_gzipped_buffer().
Signed-off-by: Laszlo Ersek <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: 07abe45c4814d42f3aca879d7932c5bc90d98bdf
https://github.com/qemu/qemu/commit/07abe45c4814d42f3aca879d7932c5bc90d98bdf
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/boot.c
M include/hw/arm/arm.h
Log Message:
-----------
hw/arm: pass pristine kernel image to guest firmware over fw_cfg
Introduce the new boolean field "arm_boot_info.firmware_loaded". When this
field is set, it means that the portion of guest DRAM that the VCPU
normally starts to execute, or the pflash chip that the VCPU normally
starts to execute, has been populated by board-specific code with
full-fledged guest firmware code, before the board calls
arm_load_kernel().
Simultaneously, "arm_boot_info.firmware_loaded" guarantees that the board
code has set up the global firmware config instance, for arm_load_kernel()
to find with fw_cfg_find().
Guest kernel (-kernel) and guest firmware (-bios, -pflash) has always been
possible to specify independently on the command line. The following cases
should be considered:
nr -bios -pflash -kernel description
unit#0
-- ------- ------- ------- -------------------------------------------
1 present present absent Board code rejects this case, -bios and
present present present -pflash unit#0 are exclusive. Left intact
by this patch.
2 absent absent present Traditional kernel loading, with qemu's
minimal board firmware. Left intact by this
patch.
3 absent present absent Preexistent case for booting guest firmware
present absent absent loaded with -bios or -pflash. Left intact
by this patch.
4 absent absent absent Preexistent case for not loading any
firmware or kernel up-front. Left intact by
this patch.
5 present absent present New case introduced by this patch: kernel
absent present present image is passed to externally loaded
firmware in unmodified form, using fw_cfg.
An easy way to see that this patch doesn't interfere with existing cases
is to realize that "info->firmware_loaded" is constant zero at this point.
Which makes the "outer" condition unchanged, and the "inner" condition
(with the fw_cfg-related code) dead.
Signed-off-by: Laszlo Ersek <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: aa351061dbb0e3054db11c00a69395785c4186c8
https://github.com/qemu/qemu/commit/aa351061dbb0e3054db11c00a69395785c4186c8
Author: Laszlo Ersek <address@hidden>
Date: 2014-12-22 (Mon, 22 Dec 2014)
Changed paths:
M hw/arm/virt.c
Log Message:
-----------
hw/arm/virt: enable passing of EFI-stubbed kernel to guest UEFI firmware
The virt board already ensures mutual exclusion between -bios and -pflash
unit#0; we only need to set "bootinfo.firmware_loaded", introduced in the
previous patch, if either of those options was used to load the guest
firmware.
Signed-off-by: Laszlo Ersek <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Commit: ab0302ee764fd702465aef6d88612cdff4302809
https://github.com/qemu/qemu/commit/ab0302ee764fd702465aef6d88612cdff4302809
Author: Peter Maydell <address@hidden>
Date: 2014-12-23 (Tue, 23 Dec 2014)
Changed paths:
M audio/audio_template.h
M exec.c
M hw/arm/boot.c
M hw/arm/exynos4210.c
M hw/arm/highbank.c
M hw/arm/integratorcp.c
M hw/arm/realview.c
M hw/arm/versatilepb.c
M hw/arm/vexpress.c
M hw/arm/virt.c
M hw/arm/xilinx_zynq.c
M hw/core/loader.c
M hw/core/machine.c
M hw/i386/pc.c
M hw/nvram/fw_cfg.c
M hw/ppc/mac_newworld.c
M hw/ppc/mac_oldworld.c
M hw/ppc/spapr.c
M hw/sparc/sun4m.c
M hw/sparc64/sun4u.c
M include/hw/arm/arm.h
M include/hw/loader.h
M include/hw/nvram/fw_cfg.h
M include/qemu/typedefs.h
M target-arm/cpu-qom.h
M target-arm/cpu.c
M target-arm/helper.c
M vl.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20141223'
into staging
target-arm queue:
* enable 32-bit EL3 (TrustZone) for vexpress and virt boards
* add fw_cfg device to virt board for UEFI firmware config
* support passing commandline kernel/initrd to firmware
# gpg: Signature made Tue 23 Dec 2014 13:50:33 GMT using RSA key ID 14360CDE
# gpg: Good signature from "Peter Maydell <address@hidden>"
* remotes/pmaydell/tags/pull-target-arm-20141223: (31 commits)
hw/arm/virt: enable passing of EFI-stubbed kernel to guest UEFI firmware
hw/arm: pass pristine kernel image to guest firmware over fw_cfg
hw/loader: split out load_image_gzipped_buffer()
arm: add fw_cfg to "virt" board
fw_cfg_mem: expose the "data_width" property with fw_cfg_init_mem_wide()
fw_cfg_mem: introduce the "data_width" property
exec: allows 8-byte accesses in subpage_ops
fw_cfg_mem: flip ctl_mem_ops and data_mem_ops to DEVICE_BIG_ENDIAN
fw_cfg_mem: max access size and region size are the same for data register
fw_cfg: move boards to fw_cfg_init_io() / fw_cfg_init_mem()
fw_cfg: hard separation between the MMIO and I/O port mappings
target-arm: add cpu feature EL3 to CPUs with Security Extensions
target-arm: Disable EL3 on unsupported machines
target-arm: Breakout integratorcp and versatilepb cpu init
target-arm: Set CPU has_el3 prop during virt init
target-arm: Enable CPU has_el3 prop during VE init
target-arm: Add arm_boot_info secure_boot control
target-arm: Add ARMCPU secure property
target-arm: Add feature unset function
target-arm: Add virt machine secure property
...
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/03de06dde54d...ab0302ee764f
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] b28fb2: audio: Don't free hw resources until after hw back...,
GitHub <=