Eduardo Habkost [Mon, 6 May 2019 21:38:17 +0000 (18:38 -0300)]
tests: Force Python I/O encoding for check-qapi-schema
test-qapi.py doesn't force a specific encoding for stderr or
stdout, but the reference files used by check-qapi-schema are in
UTF-8. This breaks check-qapi-schema under certain circumstances
(e.g. if using the C locale and Python < 3.7).
We need to make sure test-qapi.py always generate UTF-8 output
somehow. On Python 3.7+ we can do it using
`sys.stdout.reconfigure(...)`, but we need a solution that works
with older Python versions.
Instead of trying a hack like reopening sys.stdout and
sys.stderr, we can just tell Python to use UTF-8 for I/O encoding
when running test-qapi.py. Do it by setting PYTHONIOENCODING.
Peter Maydell [Tue, 7 May 2019 23:06:43 +0000 (00:06 +0100)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190507' into staging
target-arm queue:
* Stop using variable length array in dc_zva
* Implement M-profile XPSR GE bits
* Don't enable ARMV7M_EXCP_DEBUG from reset
* armv7m_nvic: NS BFAR and BFSR are RAZ/WI if BFHFNMINS == 0
* armv7m_nvic: Check subpriority in nvic_recompute_state_secure()
* fix various minor issues to allow building for Windows-on-ARM64
* aspeed: Set SDRAM size
* Allow system registers for KVM guests to be changed by QEMU code
* raspi: Diagnose requests for too much RAM
* virt: Support firmware configuration with -blockdev
* remotes/pmaydell/tags/pull-target-arm-20190507:
target/arm: Stop using variable length array in dc_zva
target/arm: Implement XPSR GE bits
hw/intc/armv7m_nvic: Don't enable ARMV7M_EXCP_DEBUG from reset
hw/intc/armv7m_nvic: NS BFAR and BFSR are RAZ/WI if BFHFNMINS == 0
hw/arm/armv7m_nvic: Check subpriority in nvic_recompute_state_secure()
osdep: Fix mingw compilation regarding stdio formats
util/cacheinfo: Use uint64_t on LLP64 model to satisfy Windows ARM64
qga: Fix mingw compilation warnings on enum conversion
QEMU_PACKED: Remove gcc_struct attribute in Windows non x86 targets
arm: aspeed: Set SDRAM size
arm: Allow system registers for KVM guests to be changed by QEMU code
hw/arm/raspi: Diagnose requests for too much RAM
hw/arm/virt: Support firmware configuration with -blockdev
pflash_cfi01: New pflash_cfi01_legacy_drive()
pc: Rearrange pc_system_firmware_init()'s legacy -drive loop
Peter Maydell [Tue, 7 May 2019 16:16:11 +0000 (17:16 +0100)]
Merge remote-tracking branch 'remotes/rth/tags/pull-dt-20190506' into staging
Add support for variable-length ISAs
# gpg: Signature made Mon 06 May 2019 19:26:21 BST
# gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg: issuer "[email protected]"
# gpg: Good signature from "Richard Henderson <[email protected]>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F
* remotes/rth/tags/pull-dt-20190506:
decodetree: Add DisasContext argument to !function expanders
decodetree: Expand a decode_load function
decodetree: Initial support for variable-length ISAs
Peter Maydell [Tue, 7 May 2019 11:55:04 +0000 (12:55 +0100)]
target/arm: Stop using variable length array in dc_zva
Currently the dc_zva helper function uses a variable length
array. In fact we know (as the comment above remarks) that
the length of this array is bounded because the architecture
limits the block size and QEMU limits the target page size.
Use a fixed array size and assert that we don't run off it.
Peter Maydell [Tue, 7 May 2019 11:55:04 +0000 (12:55 +0100)]
target/arm: Implement XPSR GE bits
In the M-profile architecture, if the CPU implements the DSP extension
then the XPSR has GE bits, in the same way as the A-profile CPSR. When
we added DSP extension support we forgot to add support for reading
and writing the GE bits, which are stored in env->GE. We did put in
the code to add XPSR_GE to the mask of bits to update in the v7m_msr
helper, but forgot it in v7m_mrs. We also must not allow the XPSR we
pull off the stack on exception return to set the nonexistent GE bits.
Correct these errors:
* read and write env->GE in xpsr_read() and xpsr_write()
* only set GE bits on exception return if DSP present
* read GE bits for MRS if DSP present
Peter Maydell [Tue, 7 May 2019 11:55:03 +0000 (12:55 +0100)]
hw/intc/armv7m_nvic: Don't enable ARMV7M_EXCP_DEBUG from reset
The M-profile architecture specifies that the DebugMonitor exception
should be initially disabled, not enabled. It should be controlled
by the DEMCR register's MON_EN bit, but we don't implement that
register yet (like most of the debug architecture for M-profile).
Note that BKPT instructions will still work, because they
will be escalated to HardFault.
Peter Maydell [Tue, 7 May 2019 11:55:03 +0000 (12:55 +0100)]
hw/intc/armv7m_nvic: NS BFAR and BFSR are RAZ/WI if BFHFNMINS == 0
The non-secure versions of the BFAR and BFSR registers are
supposed to be RAZ/WI if AICR.BFHFNMINS == 0; we were
incorrectly allowing NS code to access the real values.
Peter Maydell [Tue, 7 May 2019 11:55:03 +0000 (12:55 +0100)]
hw/arm/armv7m_nvic: Check subpriority in nvic_recompute_state_secure()
Rule R_CQRV says that if two pending interrupts have the same
group priority then ties are broken by looking at the subpriority.
We had a comment describing this but had forgotten to actually
implement the subpriority comparison. Correct the omission.
(The further tie break rules of "lowest exception number" and
"secure before non-secure" are handled implicitly by the order
in which we iterate through the exceptions in the loops.)
I encountered the following compilation error on mingw:
/mnt/d/qemu/include/qemu/osdep.h:97:9: error: '__USE_MINGW_ANSI_STDIO' macro redefined [-Werror,-Wmacro-redefined]
#define __USE_MINGW_ANSI_STDIO 1
^
/mnt/d/llvm-mingw/aarch64-w64-mingw32/include/_mingw.h:433:9: note: previous definition is here
#define __USE_MINGW_ANSI_STDIO 0 /* was not defined so it should be 0 */
It turns out that __USE_MINGW_ANSI_STDIO must be set before any
system headers are included, not just before stdio.h.
Cao Jiaxi [Tue, 7 May 2019 11:55:03 +0000 (12:55 +0100)]
qga: Fix mingw compilation warnings on enum conversion
The win2qemu[] is supposed to be the conversion table to convert between
STORAGE_BUS_TYPE in Windows SDK and GuestDiskBusType in qga.
But it was incorrectly written that it forces to set a GuestDiskBusType
value to STORAGE_BUS_TYPE, which generates an enum conversion warning in clang.
Peter Maydell [Tue, 7 May 2019 11:55:02 +0000 (12:55 +0100)]
arm: Allow system registers for KVM guests to be changed by QEMU code
At the moment the Arm implementations of kvm_arch_{get,put}_registers()
don't support having QEMU change the values of system registers
(aka coprocessor registers for AArch32). This is because although
kvm_arch_get_registers() calls write_list_to_cpustate() to
update the CPU state struct fields (so QEMU code can read the
values in the usual way), kvm_arch_put_registers() does not
call write_cpustate_to_list(), meaning that any changes to
the CPU state struct fields will not be passed back to KVM.
The rationale for this design is documented in a comment in the
AArch32 kvm_arch_put_registers() -- writing the values in the
cpregs list into the CPU state struct is "lossy" because the
write of a register might not succeed, and so if we blindly
copy the CPU state values back again we will incorrectly
change register values for the guest. The assumption was that
no QEMU code would need to write to the registers.
However, when we implemented debug support for KVM guests, we
broke that assumption: the code to handle "set the guest up
to take a breakpoint exception" does so by updating various
guest registers including ESR_EL1.
Support this by making kvm_arch_put_registers() synchronize
CPU state back into the list. We sync only those registers
where the initial write succeeds, which should be sufficient.
This commit is the same as commit 823e1b3818f9b10b824ddc which we
had to revert in commit 942f99c825fc94c8b1a4, except that the bug
which was preventing EDK2 guest firmware running has been fixed:
kvm_arm_reset_vcpu() now calls write_list_to_cpustate().
Peter Maydell [Tue, 7 May 2019 11:55:02 +0000 (12:55 +0100)]
hw/arm/raspi: Diagnose requests for too much RAM
The Raspberry Pi boards have a physical memory map which does
not allow for more than 1GB of RAM. Currently if the user tries
to ask for more then we fail in a confusing way:
$ qemu-system-aarch64 --machine raspi3 -m 8G
Unexpected error in visit_type_uintN() at qapi/qapi-visit-core.c:164:
qemu-system-aarch64: Parameter 'vcram-base' expects uint32_t
Aborted (core dumped)
Catch this earlier and diagnose it with a more friendly message:
$ qemu-system-aarch64 --machine raspi3 -m 8G
qemu-system-aarch64: Requested ram size is too large for this machine: maximum is 1GB
hw/arm/virt: Support firmware configuration with -blockdev
The ARM virt machines put firmware in flash memory. To configure it,
you use -drive if=pflash,unit=0,... and optionally -drive
if=pflash,unit=1,...
Why two -drive? This permits setting up one part of the flash memory
read-only, and the other part read/write. It also makes upgrading
firmware on the host easier. Below the hood, we get two separate
flash devices, because we were too lazy to improve our flash device
models to support sector protection.
The problem at hand is to do the same with -blockdev somehow, as one
more step towards deprecating -drive.
We recently solved this problem for x86 PC machines, in commit ebc29e1beab. See the commit message for design rationale.
This commit solves it for ARM virt basically the same way: new machine
properties pflash0, pflash1 forward to the onboard flash devices'
properties. Requires creating the onboard devices in the
.instance_init() method virt_instance_init(). The existing code to
pick up drives defined with -drive if=pflash is replaced by code to
desugar into the machine properties.
There are a few behavioral differences, though:
* The flash devices are always present (x86: only present if
configured)
* Flash base addresses and sizes are fixed (x86: sizes depend on
images, mapped back to back below a fixed address)
* -bios configures contents of first pflash (x86: -bios configures ROM
contents)
* -bios is rejected when first pflash is also configured with -machine
pflash0=... (x86: bios is silently ignored then)
* -machine pflash1=... does not require -machine pflash0=... (x86: it
does).
The actual code is a bit simpler than for x86 mostly due to the first
two differences.
Before the patch, all the action is in create_flash(), called from the
machine's .init() method machvirt_init():
main()
machine_run_board_init()
machvirt_init()
create_flash()
create_one_flash() for flash[0]
create
configure
includes obeying -drive if=pflash,unit=0
realize
map
fall back to -bios
create_one_flash() for flash[1]
create
configure
includes obeying -drive if=pflash,unit=1
realize
map
update FDT
To make the machine properties work, we need to move device creation
to its .instance_init() method virt_instance_init().
Another complication is machvirt_init()'s computation of
@firmware_loaded: it predicts what create_flash() will do. Instead of
predicting what create_flash()'s replacement virt_firmware_init() will
do, I decided to have virt_firmware_init() return what it did.
Requires calling it a bit earlier.
Resulting call tree:
main()
current_machine = object_new()
...
virt_instance_init()
virt_flash_create()
virt_flash_create1() for flash[0]
create
configure: set defaults
become child of machine [NEW]
add machine prop pflash0 as alias for drive [NEW]
virt_flash_create1() for flash[1]
create
configure: set defaults
become child of machine [NEW]
add machine prop pflash1 as alias for drive [NEW]
for all machine props from the command line: machine_set_property()
...
property_set_alias() for machine props pflash0, pflash1
...
set_drive() for cfi.pflash01 prop drive
this is how -machine pflash0=... etc set
machine_run_board_init(current_machine);
virt_firmware_init()
pflash_cfi01_legacy_drive()
legacy -drive if=pflash,unit=0 and =1 [NEW]
virt_flash_map()
virt_flash_map1() for flash[0]
configure: num-blocks
realize
map
virt_flash_map1() for flash[1]
configure: num-blocks
realize
map
fall back to -bios
virt_flash_fdt()
update FDT
You have László to thank for making me explain this in detail.
The loop does two things: map legacy -drive to properties, and collect
all the backends for use after the loop. The next patch will factor
out the former for reuse in hw/arm/virt.c. To make that easier,
rearrange the loop so it does the first thing first, and the second
thing second.
Peter Maydell [Tue, 7 May 2019 11:36:50 +0000 (12:36 +0100)]
Merge remote-tracking branch 'remotes/marcel/tags/rdma-pull-request' into staging
RDMA queue
* pvrdma: Add support for SRQ
# gpg: Signature made Sat 04 May 2019 14:35:40 BST
# gpg: using RSA key 36D4C0F0CF2FE46D
# gpg: Good signature from "Marcel Apfelbaum <[email protected]>" [marginal]
# gpg: aka "Marcel Apfelbaum <[email protected]>" [marginal]
# gpg: aka "Marcel Apfelbaum <[email protected]>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: B1C6 3A57 F92E 08F2 640F 31F5 36D4 C0F0 CF2F E46D
* remotes/marcel/tags/rdma-pull-request:
hw/pvrdma: Add support for SRQ
hw/rdma: Modify create/destroy QP to support SRQ
hw/rdma: Add support for managing SRQ resource
hw/rdma: Add SRQ support to backend layer
Fix the check preventing calling pixman functions that would access
memory outside allocated vram. The r128 X driver sometimes seem to try
blits that span outside vram, this check prevents crashing QEMU in
that case. (The r128 X driver may have problems even on real hardware
so I'm not sure if it's a client bug or emulation problem but at least
QEMU should survive.)
The SPICE_RING_PROD_ITEM() macro is initializing a local
'uint64_t *' variable to point to the 'el' field inside
the QXLReleaseRing struct. This uint64_t field is not
guaranteed aligned as the struct is packed.
Code should not take the address of fields within a
packed struct. Changing the SPICE_RING_PROD_ITEM()
macro to avoid taking the address of the field is
impractical. It is clearer to just remove the macro
and inline its functionality in the three call sites
that need it.
Commit ce3cf70edaaf split the ISA device out of the PCI one,
but forgot to remove the "hw/loader.h" header inclusion (the ISA
device calls rom_add_vga()). Remove the now unused include.
hw/display/cirrus_vga: Update the documentation URL
The documentation URL is not working, but is backed up by the
Wayback Machine on the Internet Archive.
Replace the outdated link by a captured one.
Add another link to the VGADOC4b.ZIP archive content.
When releasing spice resources in release_resource() routine,
if release info object 'ext.info' is null, it leads to null
pointer dereference. Add check to avoid it.
decodetree: Initial support for variable-length ISAs
Assuming that the ISA clearly describes how to determine
the length of the instruction, and the ISA has a reasonable
maximum instruction length, the input to the decoder can be
right-justified in an appropriate insn word.
This is not 100% convenient, as out-of-line %fields are
numbered relative to the maximum instruction length, but
this appears to still be usable.
Kamal Heib [Wed, 3 Apr 2019 11:33:42 +0000 (14:33 +0300)]
hw/rdma: Modify create/destroy QP to support SRQ
Modify create/destroy QP to support shared receive queue and rearrange
the destroy_qp() code to avoid touching the QP after calling
rdma_rm_dealloc_qp().
Peter Maydell [Fri, 3 May 2019 14:26:09 +0000 (15:26 +0100)]
Merge remote-tracking branch 'remotes/ehabkost/tags/python-next-pull-request' into staging
Python queue, 2019-05-02
* configure: automatically pick python3 is available
(Daniel P. Berrangé)
* tests/acceptance (Cleber Rosa, Philippe Mathieu-Daudé):
* Multi-architecture test support
* Multiple arch-specific boot_linux_console test cases
* Increase verbosity of avocado by default
* docstring improvements
# gpg: Signature made Fri 03 May 2019 01:40:06 BST
# gpg: using RSA key 2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <[email protected]>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/python-next-pull-request:
configure: automatically pick python3 is available
tests/boot_linux_console: add a test for alpha + clipper
tests/boot_linux_console: add a test for s390x + s390-ccw-virtio
tests/boot_linux_console: add a test for arm + virt
tests/boot_linux_console: add a test for aarch64 + virt
tests/boot_linux_console: add a test for mips64el + malta
tests/boot_linux_console: add a test for mips + malta
scripts/qemu.py: support adding a console with the default serial device
tests/boot_linux_console: refactor the console watcher into utility method
tests/boot_linux_console: increase timeout
tests/boot_linux_console: add common kernel command line options
tests/boot_linux_console: update the x86_64 kernel
tests/boot_linux_console: rename the x86_64 after the arch and machine
tests/acceptance: look for target architecture in test tags first
tests/acceptance: use "arch:" tag to filter target specific tests
tests/acceptance: introduce arch parameter and attribute
tests/acceptance: fix doc reference to avocado_qemu directory
tests/acceptance: improve docstring on pick_default_qemu_bin()
tests/acceptance: show avocado test execution by default
Signed-off-by: Peter Maydell <[email protected]>
# Conflicts:
# configure
Peter Maydell [Fri, 3 May 2019 13:57:35 +0000 (14:57 +0100)]
Merge remote-tracking branch 'remotes/lersek/tags/smbios_lp_1821884_20190503' into staging
Fix <https://bugs.launchpad.net/qemu/+bug/1821884>:
"Extend uefi-test-tools to report SMBIOS location".
# gpg: Signature made Fri 03 May 2019 10:10:31 BST
# gpg: using RSA key D39DA71E0D496CFA
# gpg: Good signature from "Laszlo Ersek <[email protected]>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: F5D9 660F 1BA5 F310 A95A C5E0 466A EAE0 6125 3988
# Subkey fingerprint: B3A5 5D3F 88A8 90ED 2E63 3E8D D39D A71E 0D49 6CFA
* remotes/lersek/tags/smbios_lp_1821884_20190503:
tests/uefi-boot-images: report the SMBIOS entry point structures
tests/uefi-test-tools: report the SMBIOS entry point structures
* remotes/kraxel/tags/usb-20190503-v2-pull-request:
hw/usb: avoid format truncation warning when formatting port name
hw/usb/hcd-ohci: Move PCI-related code into a separate file
hw/usb/hcd-ohci: Do not use PCI functions with sysbus devices in ohci_die()
usb/xhci: avoid trigger assertion if guest write wrong epid
usb-mtp: change default to success for usb_mtp_update_object
usb-mtp: fix alignment of access of ObjectInfo filename field
usb-mtp: fix string length for filename when writing metadata
tests/uefi-test-tools: report the SMBIOS entry point structures
On UEFI systems, the SMBIOS entry point (a.k.a. anchor) structures are
found similarly to the ACPI RSD PTR table(s): by scanning the
ConfigurationTable array in the EFI system table for well-known GUIDs.
Locate the SMBIOS 2.1 (32-bit) and 3.0 (64-bit) anchors in the
BiosTablesTest UEFI application, and report the addresses in new fields
appended to the BIOS_TABLES_TEST structure.
hw/usb: avoid format truncation warning when formatting port name
hw/usb/hcd-xhci.c: In function ‘usb_xhci_realize’:
hw/usb/hcd-xhci.c:3339:66: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 5 [-Wformat-trunca\
tion=]
3339 | snprintf(port->name, sizeof(port->name), "usb2 port #%d", i+1);
| ^~
hw/usb/hcd-xhci.c:3339:54: note: directive argument in the range [1, 2147483647]
3339 | snprintf(port->name, sizeof(port->name), "usb2 port #%d", i+1);
| ^~~~~~~~~~~~~~~
The xhci code formats the port name into a fixed length
buffer which is only large enough to hold port numbers
upto 5 digits in decimal representation. We're never
going to have a port number that large, so aserting the
port number is sensible is sufficient to tell GCC the
formatted string won't be truncated.
configure: automatically pick python3 is available
Unless overridden via an env var or configure arg, QEMU will only look
for the 'python' binary in $PATH. This is unhelpful on distros which
are only shipping Python 3.x (eg Fedora) in their default install as,
if they comply with PEP 394, the bare 'python' binary won't exist.
This changes configure so that by default it will search for all three
common python binaries, preferring to find Python 3.x versions.
Cleber Rosa [Tue, 12 Mar 2019 17:18:24 +0000 (13:18 -0400)]
tests/boot_linux_console: add a test for alpha + clipper
Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
board and verify the serial is working. One extra command added to
the QEMU command line is '-vga std', because the kernel used is
known to crash without it.
If alpha is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:alpha" tags.
Alternatively, this test can be run using:
$ avocado run -t arch:alpha tests/acceptance
$ avocado run -t machine:clipper tests/acceptance
tests/boot_linux_console: add a test for mips + malta
Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
board and verify the serial is working. Also, it relies on the serial
device set by the machine itself.
If mips is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:mips" tags.
Alternatively, this test can be run using:
$ avocado run -t arch:mips tests/acceptance
$ avocado run -t machine:malta tests/acceptance
$ avocado run -t endian:big tests/acceptance
Cleber Rosa [Tue, 12 Mar 2019 17:18:16 +0000 (13:18 -0400)]
scripts/qemu.py: support adding a console with the default serial device
The set_console() utility function either adds a device based on the
explicitly given device type, or adds a known good type of device
based on the machine type.
But, for a number of machine types, it may be impossible or
inconvenient to add the devices by means of "-device" command line
options, and then it may better to just use the "-serial" option and
let QEMU itself, based on the machine type, set the device
accordingly.
To achieve that, the behavior of set_console() now flags the intention
to add a console device on launch(), and if no explicit device type is
given the "-serial" option is going to be added to the QEMU command
line, instead of raising exceptions.
Based on testing with different machine types, the CONSOLE_DEV_TYPES
is not necessary anymore, so it's being removed, as is the logic to
use it.
Cleber Rosa [Tue, 12 Mar 2019 17:18:14 +0000 (13:18 -0400)]
tests/boot_linux_console: increase timeout
When running on very low powered environments, some tests may time out
causing false negatives. As a conservative change, and for
considering that human time (investigating false negatives) is worth
more than some extra machine cycles (and time), let's increase the
overall timeout.
Cleber Rosa [Tue, 12 Mar 2019 17:18:13 +0000 (13:18 -0400)]
tests/boot_linux_console: add common kernel command line options
The 'printk.time=0' option makes it easier to parse the console
output. Let's set it as a default, and reusable, kernel command line
options for this and future similar tests.
Cleber Rosa [Tue, 12 Mar 2019 17:18:11 +0000 (13:18 -0400)]
tests/boot_linux_console: rename the x86_64 after the arch and machine
Given that the test is specific to x86_64 and pc, and new tests are
going to be added to the same class, let's rename it accordingly.
Also, let's make the class documentation not architecture specific.
Cleber Rosa [Tue, 12 Mar 2019 17:18:10 +0000 (13:18 -0400)]
tests/acceptance: look for target architecture in test tags first
A test can, optionally, be tagged for one or many architectures. If a
test has been tagged for a single architecture, there's a high chance
that the test won't run on other architectures. This changes the
default order of choosing a default target architecture to use based
on the 'arch' tag value first.
The precedence order is for choosing a QEMU binary to use for a test
is now:
* qemu_bin parameter
* arch parameter
* arch tag value (for example, x86_64 if ":avocado: tags=arch:x86_64
is used)
This means that if one runs:
$ avocado run -p qemu_bin=/usr/bin/qemu-system-x86_64 test.py
No arch parameter or tag will influence the selection of the QEMU
target binary. If one runs:
$ avocado run -p arch=ppc64 test.py
The target binary selection mechanism will attempt to find a binary
such as "ppc64-softmmu/qemu-system-ppc64". And finally, if one runs
a test that is tagged (in its docstring) with "arch:aarch64":
$ avocado run aarch64.py
The target binary selection mechanism will attempt to find a binary
such as "aarch64-softmmu/qemu-system-aarch64".
At this time, no provision is made to cancel the execution of tests if
the arch parameter given (manually) does not match the test "arch"
tag, but it may be a useful default behavior to be added in the
future.
Cleber Rosa [Tue, 12 Mar 2019 17:18:09 +0000 (13:18 -0400)]
tests/acceptance: use "arch:" tag to filter target specific tests
Currently, some tests contains target architecture information, in the
form of a "x86_64" tag. But that tag is not respected in the default
execution, that is, "make check-acceptance" doesn't do anything with
it.
That said, even the target architecture handling currently present in
the "avocado_qemu.Test" class is pretty limited. For instance, by
default, it chooses a target based on the host architecture.
Because the original implementation of the tags feature in Avocado did
not include any time of namespace or "key:val" mechanism, no tag has
relation to another tag. The new implementation of the tags feature
from version 67.0 onwards, allows "key:val" tags, and because of that,
a test can be classified with a tag in a given key. For instance, the
new proposed version of the "boot_linux_console.py" test, which
downloads and attempts to run a x86_64 kernel, is now tagged as:
:avocado: tags=arch:x86_64
This means that it can be filtered (out) when no x86_64 target is
available. At the same time, tests that don't have a "arch:" tag,
will not be filtered out.
Cleber Rosa [Tue, 12 Mar 2019 17:18:08 +0000 (13:18 -0400)]
tests/acceptance: introduce arch parameter and attribute
It's useful to define the architecture that should be used in
situations such as:
* the intended target of the QEMU binary to be used on tests
* the architecture of code to be run within the QEMU binary, such
as a kernel image or a full blown guest OS image
This commit introduces both a test parameter and a test instance
attribute, that will contain such a value.
Now, when the "arch" test parameter is given, it will influence the
selection of the default QEMU binary, if one is not given explicitly
by means of the "qemu_img" parameter.
Cleber Rosa [Tue, 12 Mar 2019 17:18:07 +0000 (13:18 -0400)]
tests/acceptance: fix doc reference to avocado_qemu directory
The "this directory" reference is misleading and confusing, it's a
leftover from when this text was proposed in a README file inside
the "tests/acceptance/avocado_qemu" directory.
When that text was moved to the top level docs directory, the
reference was not updated.
Cleber Rosa [Tue, 12 Mar 2019 17:18:05 +0000 (13:18 -0400)]
tests/acceptance: show avocado test execution by default
The current version of the "check-acceptance" target will only show
one line for execution of all tests. That's probably OK if the tests
to be run are quick enough and they're always the same.
But, there's already one test alone that takes on average ~5 seconds
to run, we intend to adapt the list of tests to match the user's build
environment (among other choices).
Because of that, let's present the default Avocado UI by default.
Users can always choose a different output by setting the AVOCADO_SHOW
variable.
The slirp project is now hosted on freedesktop at:
https://gitlab.freedesktop.org/slirp.
The libslirp source was extracted from qemu/slirp filtered through
clang-format (available in project tree). The qemu slirp directory can
be swapped by a git submodule.
Peter Maydell [Thu, 2 May 2019 16:17:09 +0000 (17:17 +0100)]
Merge remote-tracking branch 'remotes/huth-gitlab/tags/pull-request-2019-05-02' into staging
- Move qtest accel code to accel/qtest.c, get rid of AccelClass->available
- Test TCG interpreter in gitlab-ci
- Small improvements to the configure script
- Use object_initialize_child in hw/pci-host
* remotes/huth-gitlab/tags/pull-request-2019-05-02:
hw/pci-host: Use object_initialize_child for correct reference counting
configure: Relax check for libseccomp
configure: Remove old *-config-devices.mak.d files when running configure
configure: Add -Wno-typedef-redefinition to CFLAGS (for Clang)
accel: Remove unused AccelClass::available field
qtest: Don't compile qtest accel on non-POSIX systems
qtest: Move accel code to accel/qtest.c
gitlab-ci.yml: Test the TCG interpreter in a CI pipeline
Thomas Huth [Tue, 30 Apr 2019 19:15:52 +0000 (21:15 +0200)]
hw/pci-host: Use object_initialize_child for correct reference counting
Both functions, object_initialize() and object_property_add_child() increase
the reference counter of the new object, so one of the references has to be
dropped afterwards to get the reference counting right. Otherwise the child
object might not be properly cleaned up when the parent gets destroyed.
Some functions of the pci-host devices miss to drop one of the references.
Fix it by using object_initialize_child() instead, which takes care of
calling object_initialize(), object_property_add_child() and object_unref()
in the right order.
Thomas Huth [Mon, 11 Mar 2019 10:20:34 +0000 (11:20 +0100)]
configure: Remove old *-config-devices.mak.d files when running configure
When running "make" in a build directory from the pre-Kconfig merge time,
the build process currently fails with:
make: *** No rule to make target `.../default-configs/pci.mak',
needed by `aarch64-softmmu/config-devices.mak'. Stop.
To make sure that this problem at least goes away when the user runs
"configure" (or "sh config.status") again, we have to make sure that
we re-generate the .mak.d files. Thus remove the old stale files
while running the configure script.
Thomas Huth [Wed, 24 Apr 2019 11:05:25 +0000 (13:05 +0200)]
configure: Add -Wno-typedef-redefinition to CFLAGS (for Clang)
Without the -Wno-typedef-redefinition option, clang complains if a typedef
gets redefined in gnu99 mode (since this is officially a C11 feature). This
used to also happen with older versions of GCC, but since we've bumped our
minimum GCC version to 4.8, all versions of GCC that we support do not seem
to issue this warning in gnu99 mode anymore. So this has become a common
problem for people who only test their code with GCC - they do not notice
the issue until they submit their patches and suddenly patchew or a
maintainer complains.
Now that we do not urgently need to keep the code clean from typedef
redefintions anymore with recent versions of GCC, we can ease the
situation with clang, too, and simply shut these warnings off for good.
qtest: Don't compile qtest accel on non-POSIX systems
qtest_available() will always return 0 on non-POSIX systems.
It's simpler to just not compile the accelerator code on those
systems instead of relying on the AccelClass::available function.
QTest has two parts: the server (-qtest) and the accelerator
(-machine accel=qtest). The accelerator depends on CONFIG_POSIX
due to its usage of sigwait(), but the server doesn't.
Move the accel code to accel/qtest.c. Later we will disable
compilation of accel/qtest.c on non-POSIX systems.
Thomas Huth [Wed, 10 Apr 2019 12:35:50 +0000 (14:35 +0200)]
gitlab-ci.yml: Test the TCG interpreter in a CI pipeline
So far we do not have any test coverage for TCI (the TCG interpreter) yet.
Thus let's add a CI pipeline that runs at least some basic TCG tests with
a TCI build, to make sure that there are no further regressions.
Thomas Huth [Fri, 19 Apr 2019 07:56:25 +0000 (09:56 +0200)]
hw/usb/hcd-ohci: Move PCI-related code into a separate file
Some machines (like the pxa2xx-based ARM machines) only have a sysbus
OHCI controller, but no PCI. With the new Kconfig-style build system,
it will soon be possible to create QEMU binaries that only contain
such PCI-less machines. However, the two OHCI controllers, for sysbus
and for PCI, are currently both located in one file, so the PCI code
is still required for linking here. Move the OHCI-PCI device code
into a separate file, so that it is possible to use the sysbus OHCI
device also without the PCI dependency.
Thomas Huth [Fri, 19 Apr 2019 07:56:24 +0000 (09:56 +0200)]
hw/usb/hcd-ohci: Do not use PCI functions with sysbus devices in ohci_die()
The ohci_die() function always assumes to be running with a PCI OHCI
controller and calls the PCI-specific functions pci_set_word(). However,
this function might also get called for the sysbus OHCI devices, so it
likely fails in that case. To fix this issue, change the code now, so that
there are two implementations now, one for sysbus and one for PCI, and
use the right function via a function pointer in the OHCIState structure.
usb/xhci: avoid trigger assertion if guest write wrong epid
we found the following core in our environment:
0 0x00007fc6b06c2237 in raise ()
1 0x00007fc6b06c3928 in abort ()
2 0x00007fc6b06bb056 in __assert_fail_base ()
3 0x00007fc6b06bb102 in __assert_fail ()
4 0x0000000000702e36 in xhci_kick_ep (...)
5 0x000000000047897a in memory_region_write_accessor (...)
6 0x000000000047767f in access_with_adjusted_size (...)
7 0x000000000047944d in memory_region_dispatch_write (...)
(mr=mr@entry=0x7fc6a0138df0, addr=addr@entry=156, data=1648892416,
size=size@entry=4, attrs=attrs@entry=...)
8 0x000000000042df17 in address_space_write_continue (...)
10 0x000000000043084d in address_space_rw (...)
11 0x000000000047451b in kvm_cpu_exec (cpu=cpu@entry=0x1ab11b0)
12 0x000000000045dcf5 in qemu_kvm_cpu_thread_fn (arg=0x1ab11b0)
13 0x0000000000870631 in qemu_thread_start (args=args@entry=0x1acfb50)
14 0x00000000008959a7 in thread_entry_for_hotfix (pthread_cb=<optimized out>)
15 0x00007fc6b0a60dd5 in start_thread ()
16 0x00007fc6b078a59d in clone ()
(gdb) f 5
5 0x000000000047897a in memory_region_write_accessor (...)
529 mr->ops->write(mr->opaque, addr, tmp, size);
(gdb) p /x tmp
$9 = 0x62481a00 <-- last byte 0x00 is @epid
xhci_doorbell_write() already check the upper bound of @slotid an @epid,
it also need to check the lower bound.
Bandan Das [Mon, 15 Apr 2019 16:47:12 +0000 (12:47 -0400)]
usb-mtp: change default to success for usb_mtp_update_object
Commit c5ead51f90cf (usb-mtp: return incomplete transfer on a lstat
failure) checks if lstat succeeded when updating attributes of a
file. However, it also changed behavior to return an error by
default. This is incorrect because for smaller file sizes, Qemu
will attempt to write the file in one go and there won't be
an object for it.
usb-mtp: fix alignment of access of ObjectInfo filename field
The ObjectInfo struct's "filename" field is following a uint8_t
field in a packed struct and thus has bad alignment for a 16-bit
field. Switch the field to to uint8_t and use the helper function
for accessing unaligned 16-bit data.
Note that although the MTP spec specifies big endian, when transported
over the USB protocol, data is little endian.
usb-mtp: fix string length for filename when writing metadata
The ObjectInfo 'length' field provides the length of the
wide character string filename. This is then converted to
a multi-byte character string. This may have a different
byte count to the wide character string. We should use the
C string length of the multi-byte string instead.
John Snow [Fri, 26 Apr 2019 22:15:28 +0000 (18:15 -0400)]
docs/interop/bitmaps: rewrite and modernize doc
This just about rewrites the entirety of the bitmaps.rst document to
make it consistent with the 4.0 release. I have added new features seen
in the 4.0 release, as well as tried to clarify some points that keep
coming up when discussing this feature both in-house and upstream.
It does not yet cover pull backups or migration details, but I intend to
keep extending this document to cover those cases.
Add a gva2gpa command purely for debug which performs
address translation on the gva, the existing gpa2hva
command can then also be used to find it in the qemu
userspace; e.g.
This gives us the consistent 'Error:' prefix added in 66363e9a43f,
which helps users like libvirt who still need to scrape hmp error
messages to detect failure.
Peter Maydell [Tue, 30 Apr 2019 16:06:57 +0000 (17:06 +0100)]
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
Block layer patches:
- iotests: Fix output of qemu-io related tests
- Don't ignore bdrv_set_aio_context() for nodes with bs->drv = NUL
- vmdk: Set vmdk parent backing_format to vmdk
- qcow2: Preallocation fixes (especially for external data files)
- Add linear-buffer-based APIs (as wrappers around qiov-based ones)
- Various code cleanups and small corner case fixes
# gpg: Signature made Tue 30 Apr 2019 16:35:09 BST
# gpg: using RSA key 7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <[email protected]>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* remotes/kevin/tags/for-upstream: (27 commits)
block/qed: add missed coroutine_fn markers
iotests: Check that images are in read-only mode after block-commit
commit: Make base read-only if there is an early failure
qemu-img: use buffer-based io
block/stream: use buffer-based io
block/commit: use buffer-based io
block/backup: use buffer-based io
block/parallels: use buffer-based io
block/qed: use buffer-based io
block/qcow: use buffer-based io
block/qcow2: use buffer-based io
block: introduce byte-based io helpers
qcow2: Fix error handling in the compression code
qcow2: Fix qcow2_make_empty() with external data file
qemu-img: Make create hint at protocol options
iotests: Perform the correct test in 082
qcow2: Fix full preallocation with external data file
qcow2: Add errp to preallocate_co()
qcow2: Avoid COW during metadata preallocation
qemu-img: Saner printing of large file sizes
...
qed_read_table and qed_write_table use coroutine-only interfaces but
are not marked coroutine_fn. Happily, they are called only from
coroutine context, so we only need to add missed markers.
Alberto Garcia [Mon, 29 Apr 2019 13:51:08 +0000 (15:51 +0200)]
commit: Make base read-only if there is an early failure
You can reproduce this by passing an invalid filter-node-name (like
"1234") to block-commit. In this case the base image is put in
read-write mode but is never reset back to read-only.
projects / qemu.git / log