Entries are inserted in filename order instead of being
appended to the end in case sorting is enabled.
This will avoid any future issues of moving the file creation
around, it doesn't matter what order they are created now,
the will always be in filename order.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Added machine type handling for compatibility. This was
a fairly complex change, this will preserve the order of fw_cfg
for older versions no matter what order the firmware files
actually come in. A list is kept of the correct legacy order
and the entries will be inserted based upon their order in
the list. Except that some entries are ordered (in a specific
area of the list) based upon what order they appear on the
command line. Special handling is added for those entries.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Fix a typo in the load_image_mr() macro: 'mr' was written when
the parameter name is '_mr'. (This had no visible effects since
the single use of the macro used 'mr' as the argument.)
Fixes 76151cacfe "loader: Add
load_image_mr() to load ROM image to a MemoryRegion"
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Some CPUs are of an opposite data-endianness to other components in the
system. Sometimes elfs have the data sections layed out with this CPU
data-endianness accounting for when loaded via the CPU, so byte swaps
(relative to other system components) will occur.
The leading example, is ARM's BE32 mode, which is is basically LE with
address manipulation on half-word and byte accesses to access the
hw/byte reversed address. This means that word data is invariant
across LE and BE32. This also means that instructions are still LE.
The expectation is that the elf will be loaded via the CPU in this
endianness scheme, which means the data in the elf is reversed at
compile time.
As QEMU loads via the system memory directly, rather than the CPU, we
need a mechanism to reverse elf data endianness to implement this
possibility.
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Document the usage of load_elf() for clarity on current features.
Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add an API to load an elf header header from a file. Populates a
buffer with the header contents, as well as a boolean for whether the
elf is 64b or not. Both arguments are optional.
Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[PMM: Fix typo in comment]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Add a new function load_image_mr(), which behaves like
load_image_targphys() except that it loads the ROM image to
a specified MemoryRegion rather than to a specified physical
address. This is useful when a ROM blob needs to be loaded
to a particular flash or ROM device but the address of that
device in the machine's address space is not known. (For
instance, ROMs in devices, or ROMs which might exist in
a different address space to the system address space.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1455288361-30117-3-git-send-email-peter.maydell@linaro.org
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
On ARM, commit ac9d32e396 postponed the
memory preparation for boot until the machine init done notifier. This
has for consequence to insert ROM at machine init done time.
However the rom_load_all function stayed called before the ROM are
inserted. As a consequence the rom_load_all function does not do
everything it is expected to do, on ARM.
It currently registers the ROM reset notifier but does not iterate through
the registered ROM list. the isrom field is not set properly. This latter
is used to report info in the monitor and also to decide whether the
rom->data can be freed on ROM reset notifier.
To fix that regression the patch moves the rom_load_all call after
machine init done. We also take the opportunity to rename the rom_load_all
function into rom_check_and_resgister_reset() and integrate the
rom_load_done in it.
Signed-off-by: Eric Auger <eric.auger@linaro.org>
Reported-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-Id: <1434470874-22573-1-git-send-email-eric.auger@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
ram_addr_t is an internal interface, everyone should go through
MemoryRegion. Clean it up by making rom_add_blob return a
MemoryRegion* and using the new qemu_ram_resize infrastructure.
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Some are called do_info_SUBCOMMAND() (old ones, usually), some
hmp_info_SUBCOMMAND(), some SUBCOMMAND_info(), sometimes SUBCOMMAND
pointlessly differs in spelling.
Normalize to hmp_info_SUBCOMMAND(), where SUBCOMMAND is exactly the
subcommand name with '-' replaced by '_'.
Exceptions:
* sun4m_irq_info(), sun4m_pic_info() renamed to sun4m_hmp_info_irq(),
sun4m_hmp_info_pic().
* lm32_irq_info(), lm32_pic_info() renamed to lm32_hmp_info_irq(),
lm32_hmp_info_pic().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
This makes ROM blocks resizeable. This infrastructure is required for other
functionality we have queued.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUrme8AAoJECgfDbjSjVRpqmEH/1APnrphAi/CM6rxf2hPyvWj
f5yQDNXfeGxrHaW5vux6DvgHUkTng6KGBxz6XMSiwul6MeyRFNDqwbfMhSHjiIum
QkT//jqb5xux60kyTLXuIBTPok1SsKDtaTxbvZb0VmZrnkdYeI2CLa1Mq3cQUY0a
8DKnchQEM5lic9bxj+OuLiDFx8QYaMpQlUP9iIvNq6GjX+0zNsWvfPtkMTm00t93
lHKPvD2eVmrgfS5g+lkAwLDahLSjqwDc0YuLABOgDUFsZFz9GAUCHSpt0y8HEBwR
1NhGCfbnyyRl/1OSULtARGQ4Ddwm5dn1i5I4usoP5rLFS7FV5F7xhBu0IZlwgVA=
=pFmm
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
pc: resizeable ROM blocks
This makes ROM blocks resizeable. This infrastructure is required for other
functionality we have queued.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Thu 08 Jan 2015 11:19:24 GMT using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>"
* remotes/mst/tags/for_upstream:
acpi-build: make ROMs RAM blocks resizeable
memory: API to allocate resizeable RAM MR
arch_init: support resizing on incoming migration
exec: qemu_ram_alloc_resizeable, qemu_ram_resize
exec: split length -> used_length/max_length
exec: cpu_physical_memory_set/clear_dirty_range
memory: add memory_region_set_size
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Use resizeable ram API so we can painlessly extend ROMs in the
future. Note: migration is not affected, as we are
not actually changing the used length for RAM, which
is the part that's migrated.
Use this in acpi: reserve x16 more RAM space.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
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 <lersek@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1419250305-31062-10-git-send-email-pbonzini@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
acpi build modifies internal FW CFG RAM on first access
but we forgot to mark it dirty.
If this RAM has been migrated already, it won't be
migrated again, returning corrupted tables to guest.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Such address translation is needed when load address recorded in uImage
is a virtual address. When the actual load address is requested, return
untranslated address: user that needs the translated address can always
apply translation function to it and those that need it untranslated
don't need to do the inverse translation.
Add translation function pointer and its parameter to uimage_load
prototype. Update all existing users.
No user-visible functional changes.
Cc: qemu-stable@nongnu.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
A subsequent patch to ppc/spapr needs to load the RTAS blob into
qemu memory rather than target memory (so it can later be copied
into the right spot at machine reset time).
I would use load_image() but it is marked deprecated because it
doesn't take a buffer size as argument, so let's add load_image_size()
that does.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[aik: fixed errors from checkpatch.pl]
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
As the name suggests this lets you load a ROM/disk image that is
gzipped. It is uncompressed before storing it in guest memory.
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 1407831259-2115-2-git-send-email-rjones@redhat.com
[PMM: removed stray space before ')']
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Since
commit 04920fc0fa
loader: store FW CFG ROM files in RAM
RAM MRs including ROM files in FW CFGs are created
and named using the file basename.
This becomes problematic if these names are
supplied by user, since the basename might not
be unique.
There are two cases we care about:
- option-rom flag.
- option ROM for devices. This triggers e.g. when
using rombar=0.
At the moment we get an assert. E.g
qemu -option-rom /usr/share/ipxe/8086100e.rom -option-rom
/usr/share/ipxe.efi/8086100e.rom
RAMBlock "/rom@genroms/8086100e.rom" already registered, abort!
This is a regression from 1.6.
For now let's keep it simple and just avoid creating the
MRs in case of option ROMs.
when using 1.7 machine types, enable
option ROMs in RAM to match that version.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
we put copy of ROMs in MR for migration.
but the name rom_in_ram makes one think we
load it in guest RAM.
Rename has_mr to make intent clearer.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The existing load_elf() just returns -1 if it fails to load ELF. However
it could be smarter than this and tell more about the failure such as
wrong endianness or incompatible platform.
This adds additional return codes for wrong architecture, wrong
endianness and if the image is not ELF at all.
This adds a load_elf_strerror() helper to convert return codes into
string messages.
This fixes handling of what load_elf() returns for s390x, other
callers just check the return value for <0 and this remains unchanged.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Alexander Graf <agraf@suse.de>
Document that get_image_size sets errno
on failure.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
rom_add_blob never fails, and neither does rom_add_blob_fixed,
so there's no need to return value from it.
In fact, rom_add_blob_fixed was erroneously returning -1 unconditionally
which made the only system that checked the return value -M bamboo fail
to start.
Drop the return value and drop checks from ppc440_bamboo to
fix this failure.
Reported-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Support ROM blobs not mapped into guest memory:
same as ROM files really but use caller's buffer.
Support invoking callback on access and
return memory pointer making it easier
for caller to update memory if necessary.
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
ROM files that are put in FW CFG are copied to guest ram, by BIOS, but
they are not backed by RAM so they don't get migrated.
Each time we change two bytes in such a ROM this breaks cross-version
migration: since we can migrate after BIOS has read the first byte but
before it has read the second one, getting an inconsistent state.
Future-proof this by creating, for each such ROM,
an MR serving as the backing store.
This MR is never mapped into guest memory, but it's registered
as RAM so it's migrated with the guest.
Naturally, this only helps for -M 1.7 and up, older machine types
will still have the cross-version migration bug.
Luckily the race window for the problem to trigger is very small,
which is also likely why we didn't notice the cross-version
migration bug in testing yet.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Introduce 'load_ramdisk()' which can load "normal" ramdisks and ramdisks
with a u-boot header.
To enable this and leverage synergies 'load_uimage()' is refactored to
accomodate this additional use case.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1373323202-17083-2-git-send-email-soren.brinkmann@xilinx.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Currently some places use pointer-to-void even though they mean
pointer-to-FWCfgState. Clean them up.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it necessary to compile these files per-target.
However, fixing this does not belong in these patches.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
