Avoid orphan memory regions being added in the /unattached QOM
container.
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The scripts/coccinelle/memory-region-housekeeping.cocci reported:
* TODO [[view:./hw/ppc/ppc405_boards.c::face=ovl-face1::linb=195::colb=8::cole=30][potential use of memory_region_init_rom*() in ./hw/ppc/ppc405_boards.c::195]]
* TODO [[view:./hw/ppc/ppc405_boards.c::face=ovl-face1::linb=464::colb=8::cole=30][potential use of memory_region_init_rom*() in ./hw/ppc/ppc405_boards.c::464]]
We can indeed replace the memory_region_init_ram() and
memory_region_set_readonly() calls by memory_region_init_rom().
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The scripts/coccinelle/memory-region-housekeeping.cocci reported:
* TODO [[view:./hw/arm/stm32f205_soc.c::face=ovl-face1::linb=96::colb=4::cole=26][potential use of memory_region_init_rom*() in ./hw/arm/stm32f205_soc.c::96]]
* TODO [[view:./hw/arm/stm32f405_soc.c::face=ovl-face1::linb=98::colb=4::cole=26][potential use of memory_region_init_rom*() in ./hw/arm/stm32f405_soc.c::98]]
We can indeed replace the memory_region_init_ram() and
memory_region_set_readonly() calls by memory_region_init_rom().
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Avoid orphan memory regions being added in the /unattached QOM
container.
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Avoid orphan memory regions being added in the /unattached QOM
container.
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Avoid orphan memory regions being added in the /unattached QOM
container.
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Avoid orphan memory regions being added in the /unattached QOM
container.
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Avoid orphan memory regions being added in the /unattached QOM
container.
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
When a device creates a MemoryRegion without setting its ownership,
the MemoryRegion is added to the machine "/unattached" container in
the QOM tree.
Example with the Samsung SMDKC210 board:
$ arm-softmmu/qemu-system-arm -M smdkc210 -S -monitor stdio
(qemu) info qom-tree
/machine (smdkc210-machine)
/unattached (container)
/io[0] (qemu:memory-region)
/exynos4210.dram0[0] (qemu:memory-region)
/exynos4210.irom[0] (qemu:memory-region)
/exynos4210.iram[0] (qemu:memory-region)
/exynos4210.chipid[0] (qemu:memory-region)
...
/device[26] (exynos4210.uart)
/exynos4210.uart[0] (qemu:memory-region)
/soc (exynos4210)
^
\__ [*]
The irom/iram/chipid regions should go under 'soc' at [*].
Add a semantic patch to let the device own the memory region.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Add a semantic patch to detect potential replacement of
memory_region_init_ram(readonly) by memory_region_init_rom().
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Reviewed-by: KONRAD Frederic <frederic.konrad@adacore.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This commit was produced with the Coccinelle script
scripts/coccinelle/memory-region-housekeeping.cocci.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Add a semantic patch to replace memory_region_init_ram(readonly)
by memory_region_init_rom().
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
As we are going to add various semantic changes related to the memory
region API, rename this script to be more generic.
Add a 'usage' header, and an entry in MAINTAINERS to avoid checkpatch
warning.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
memory_region_init_rom_nomigrate() has the same content than
memory_region_init_ram_shared_nomigrate(), with setting the
readonly mode. The code is easier to review as creating a
readonly ram/shared/nomigrate region.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Since memory region aliases are neither rom nor ram, they are
described as i/o, which is often incorrect. Return instead the
type of the original region we are aliasing.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The polymorphic locking macros don't support QemuRecMutex yet. Add it
so that lock guards can be used with QemuRecMutex.
Convert TCG plugins functions that benefit from these macros. Manual
qemu_rec_mutex_lock/unlock() callers are left unmodified in cases where
clarity would not improve by switching to the macros.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch introduces two lock guard macros that automatically unlock a
lock object (QemuMutex and others):
void f(void) {
QEMU_LOCK_GUARD(&mutex);
if (!may_fail()) {
return; /* automatically unlocks mutex */
}
...
}
and:
WITH_QEMU_LOCK_GUARD(&mutex) {
if (!may_fail()) {
return; /* automatically unlocks mutex */
}
}
/* automatically unlocks mutex here */
...
Convert qemu-timer.c functions that benefit from these macros as an
example. Manual qemu_mutex_lock/unlock() callers are left unmodified in
cases where clarity would not improve by switching to the macros.
Many other QemuMutex users remain in the codebase that might benefit
from lock guards. Over time they can be converted, if that is
desirable.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
[Use QEMU_MAKE_LOCKABLE_NONNULL. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This will be needed for lock guards, because if the lock is NULL the
dummy for loop of the lock guard never runs. This can cause confusion
and dummy warnings in the compiler, but even if it did not, aborting
with a NULL pointer dereference is a less surprising behavior.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We found an issue when repeat reboot in guest during migration, it cause the
migration thread never be waken up again.
<main loop> |<migration_thread>
|
LOCK BQL |
... |
main_loop_should_exit |
pause_all_vcpus |
1. set all cpus ->stop=true |
and then kick |
2. return if all cpus is paused |
(by '->stopped == true'), else|
3. qemu_cond_wait [BQL UNLOCK] |
|LOCK BQL
|...
|do_vm_stop
| pause_all_vcpus
| (A)set all cpus ->stop=true
| and then kick
| (B)return if all cpus is paused
| (by '->stopped == true'), else
| (C)qemu_cond_wait [BQL UNLOCK]
4. be waken up and LOCK BQL | (D)be waken up BUT wait for BQL
5. goto 2. |
(BQL is still LOCKed) |
resume_all_vcpus |
1. set all cpus ->stop=false |
and ->stopped=false |
... |
BQL UNLOCK | (E)LOCK BQL
| (F)goto B. [but stopped is false now!]
|Finally, sleep at step 3 forever.
resume_all_vcpus should notice this race, so we need to move the change
of runstate before pause_all_vcpus in do_vm_stop() and ignore the resume
request if runstate is not running.
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Longpeng <longpeng2@huawei.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200316083732.2010-1-longpeng2@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit 355477f8c7 skips rom reset when we're an incoming migration
so as not to overwrite shared ram in the ignore-shared migration
optimisation.
However, it's got an unexpected side effect that because it skips
freeing the ROM data, when rom_reset gets called later on, after
migration (e.g. during a reboot), the ROM does get reset to the original
file contents. Because of seabios/x86's weird reboot process
this confuses a reboot into hanging after a migration.
Fixes: 355477f8c7 ("migration: do not rom_reset() during incoming migration")
https://bugzilla.redhat.com/show_bug.cgi?id=1809380
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
glibc and Linux-provided headers are known to generate macro
redefinition warnings when used together. For example:
<linux/mman.h> and <sys/mman.h> duplicate some macro definitions.
We normally never see those warnings because GCC suppresses
warnings generated by system headers. We carry our own copy of
Linux header files, though, and this makes those warnings not be
suppressed when glibc headers are included before Linux headers
(e.g. if <sys/mman.h> is included before <linux/mman.h>).
Use -isystem instead of -I for linux-headers. This makes the
compiler treat our linux-headers directory the same way it treats
system-provided Linux headers, and suppress warnings generated by
them.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently if you try to ask for the list of CPUs for a target
architecture which does not specify a default machine type
you just get an error:
$ qemu-system-arm -cpu help
qemu-system-arm: No machine specified, and there is no default
Use -machine help to list supported machines
Since the list of CPUs doesn't depend on the machine, this is
unnecessarily unhelpful. "-device help" has a similar problem.
Move the checks for "did the user ask for -cpu help or -device help"
up so they precede the select_machine() call which checks that the
user specified a valid machine type.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- Add the '-noTSX' variants for CascadeLake and SkyLake.
- Document the three MSR bits: 'mds-no', 'taa-no', and 'tsx-ctrl'
Two confusing things about 'mds-no' (and the first point applies to
the other two MSRs too):
(1) The 'mds-no' bit will _not_ show up in the guest's /proc/cpuinfo.
Rather it is used to fill in the guest's sysfs:
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
Paolo confirmed on IRC as such.
(2) There are _three_ variants[+] of CascadeLake CPUs, with different
stepping levels: 5, 6, and 7. To quote wikichip.org[*]:
"note that while steppings 6 & 7 are fully mitigated, earlier
stepping 5 is not protected against MSBDS, MLPDS, nor MDSUM"
The above is also indicated in the Intel's document[+], as
indicated by "No" under the three columns of MFBDS, MSBDS, and
MLPDS.
I've expressed this in the docs without belabouring the details.
[+] https://software.intel.com/security-software-guidance/insights/processors-affected-microarchitectural-data-sampling
[*] https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#Key_changes_from_Skylake
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Message-Id: <20200225165618.6571-3-kchamart@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We only need these arrays when using the curses display.
Move them from the .bss to the .heap (sizes reported on
x86_64 host: screen[] is 64KiB, vga_to_curses 7KiB).
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
As we only use this array as input, make it const.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The USB descriptor sizes are specified as 16-bit for idVendor /
idProduct, and 8-bit for bInterfaceClass / bInterfaceSubClass /
bInterfaceProtocol. Doing so we reduce the usbredir_raw_serial_ids[]
and usbredir_ftdi_serial_ids[] arrays from 16KiB to 6KiB (size
reported on x86_64 host, building with --extra-cflags=-Os).
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The intel-hda model uses an array of register indexed by the
register address. This array also contains a pair of aliased
registers at offset 0x2000. This creates a huge hole in the
array, which ends up eating 4.6MiB of .rodata (size reported
on x86_64 host, building with --extra-cflags=-Os).
By using a memory region alias, we reduce this array to 132kB.
Before:
(qemu) info mtree
00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda
After:
(qemu) info mtree
00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda
00000000febd4000-00000000febd7fff (prio 1, i/o): intel-hda-container
00000000febd4000-00000000febd5fff (prio 0, i/o): intel-hda
00000000febd6000-00000000febd7fff (prio 0, i/o): alias intel-hda-alias @intel-hda 0000000000000000-0000000000001fff
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This buffer is only used by the adlib audio device. Move it to
the .heap to release 32KiB of .bss (size reported on x86_64 host).
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The 'help' target is displayed unaligned. Add a print-help
function and use it. Now if someone want to change the
indentation, there is a single place to modify.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
WHPX wasn't using the proper synchronization primitives while
processing async events, which can cause issues with SMP.
Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When HAX is enabled (--enable-hax), GCC 9.2.1 reports issues with
snprintf(). Replacing old snprintf() by g_strdup_printf() fixes the
problem with boundary checks of vm_id and vcpu_id and finally the
warnings produced by GCC.
For more details, one example of warning:
CC i386-softmmu/target/i386/hax-posix.o
qemu/target/i386/hax-posix.c: In function ‘hax_host_open_vm’:
qemu/target/i386/hax-posix.c:124:56: error: ‘%02d’ directive output may be
truncated writing between 2 and 11 bytes into a region of size 3
[-Werror=format-truncation=]
124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id);
| ^~~~
qemu/target/i386/hax-posix.c:124:41: note: directive argument in the range
[-2147483648, 64]
124 | snprintf(name, sizeof HAX_VM_DEVFS, "/dev/hax_vm/vm%02d", vm_id);
| ^~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/stdio.h:867,
from qemu/include/qemu/osdep.h:99,
from qemu/target/i386/hax-posix.c:14:
/usr/include/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output
between 17 and 26 bytes into a destination of size 17
67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68 | __bos (__s), __fmt, __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Several objects implemented their own uint property getters and setters,
despite them being straightforward (without any checks/validations on
the values themselves) and identical across objects. This makes use of
an enhanced API for object_property_add_uintXX_ptr() which offers
default setters.
Some of these setters used to update the value even if the type visit
failed (eg. because the value being set overflowed over the given type).
The new setter introduces a check for these errors, not updating the
value if an error occurred. The error is propagated.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently, ich9_lpc_initfn simply serves as a caller to
ich9_lpc_add_properties. This simplifies the code a bit by eliminating
ich9_lpc_add_properties altogether and executing its logic in the parent
object initialiser function.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When QOM APIs were added to ich9 in 6f1426ab, the getter for sci_int was
written using uint32_t. However, the object property is uint8_t. This
fixes the getter for correctness.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Traditionally, the uint-specific property helpers only offer getters.
When adding object (or class) uint types, one must therefore use the
generic property helper if a setter is needed (and probably duplicate
some code writing their own getters/setters).
This enhances the uint-specific property helper APIs by adding a
bitwise-or'd 'flags' field and modifying all clients of that API to set
this paramater to OBJ_PROP_FLAG_READ. This maintains the current
behaviour whilst allowing others to also set OBJ_PROP_FLAG_WRITE (or use
the more convenient OBJ_PROP_FLAG_READWRITE) in the future (which will
automatically install a setter). Other flags may be added later.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently only the final page offset is being passed to the `log_clear`
hook via `memory_region_clear_dirty_bitmap` after it is used as an
iterator in `cpu_physical_memory_test_and_clear_dirty`. This patch
corrects the start address and size of the region.
Signed-off-by: Matt Borgerson <contact@mborgerson.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Install the SASL library to build the VNC SASL auth protocol code.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200309122454.22551-3-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The Simple Authentication and Security Layer (SASL) library
re-defines the struct iovec on Win32 [*]. QEMU also re-defines
it in "qemu/osdep.h". The two definitions then clash on a MinGW
build.
We can avoid the SASL definition by defining STRUCT_IOVEC_DEFINED.
Since QEMU already defines 'struct iovec' if it is missing, add
the definition to vnc_sasl_cflags to avoid SASL re-defining it.
[*] https://github.com/cyrusimap/cyrus-sasl/blob/cyrus-sasl-2.1.27/include/sasl.h#L187
Cc: Alexey Pavlov <alexpux@gmail.com>
Cc: Biswapriyo Nath <nathbappai@gmail.com>
Reported-by: Youry Metlitsky <winaes@yandex.ru>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200309122454.22551-2-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
On upgrades the old .so files usually are replaced. But on the other
hand since a qemu process represents a guest instance it is usually kept
around.
That makes late addition of dynamic features e.g. 'hot-attach of a ceph
disk' fail by trying to load a new version of e.f. block-rbd.so into an
old still running qemu binary.
This adds a fallback to also load modules from a versioned directory in the
temporary /var/run path. That way qemu is providing a way for packaging
to store modules of an upgraded qemu package as needed until the next reboot.
An example how that can then be used in packaging can be seen in:
https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/log/?h=bug-1847361-miss-old-so-on-upgrade-UBUNTU
Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20200310145806.18335-2-christian.ehrhardt@canonical.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
