Peter Maydell [Mon, 8 Jul 2019 16:40:05 +0000 (17:40 +0100)]
Merge remote-tracking branch 'remotes/stefanberger/tags/pull-tpm-2019-07-08-1' into staging
Merge tpm 2019/07/08 v1
# gpg: Signature made Mon 08 Jul 2019 15:04:46 BST
# gpg: using RSA key 75AD65802A0B4211
# gpg: Good signature from "Stefan Berger <stefanb@linux.vnet.ibm.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: B818 B9CA DF90 89C2 D5CE C66B 75AD 6580 2A0B 4211
* remotes/stefanberger/tags/pull-tpm-2019-07-08-1:
hw/tpm: Only build tpm_ppi.o if any of TPM_TIS/TPM_CRB is built
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Mon, 8 Jul 2019 14:21:20 +0000 (15:21 +0100)]
Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging
Block layer patches:
- virtio-scsi: Fix request resubmission after I/O error with iothreads
- qcow2: Fix missing v2/v3 subformat aliases for amend
- qcow(1): More specific error message for wrong format version
- MAINTAINERS: update RBD block maintainer
# gpg: Signature made Mon 08 Jul 2019 15:17:27 BST
# gpg: using RSA key 7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* remotes/kevin/tags/for-upstream:
qcow2: Allow -o compat=v3 during qemu-img amend
MAINTAINERS: update RBD block maintainer
block/qcow: Improve error when opening qcow2 files as qcow
virtio-scsi: restart DMA after iothread
qdev: add qdev_add_vm_change_state_handler()
vl: add qemu_add_vm_change_state_handler_prio()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Eric Blake [Fri, 5 Jul 2019 15:28:12 +0000 (10:28 -0500)]
qcow2: Allow -o compat=v3 during qemu-img amend
Commit b76b4f60 allowed '-o compat=v3' as an alias for the
less-appealing '-o compat=1.1' for 'qemu-img create' since we want to
use the QMP form as much as possible, but forgot to do likewise for
qemu-img amend. Also, it doesn't help that '-o help' doesn't list our
new preferred spellings.
Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
John Snow [Wed, 26 Jun 2019 21:53:01 +0000 (17:53 -0400)]
block/qcow: Improve error when opening qcow2 files as qcow
Reported-by: radmehrsaeed7@gmail.com Fixes: https://bugs.launchpad.net/bugs/1832914 Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Stefan Hajnoczi [Thu, 20 Jun 2019 17:37:09 +0000 (18:37 +0100)]
virtio-scsi: restart DMA after iothread
When the 'cont' command resumes guest execution the vm change state
handlers are invoked. Unfortunately there is no explicit ordering
between classic qemu_add_vm_change_state_handler() callbacks. When two
layers of code both use vm change state handlers, we don't control which
handler runs first.
virtio-scsi with iothreads hits a deadlock when a failed SCSI command is
restarted and completes before the iothread is re-initialized.
This patch uses the new qdev_add_vm_change_state_handler() API to
guarantee that virtio-scsi's virtio change state handler executes before
the SCSI bus children. This way DMA is restarted after the iothread has
re-initialized.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Stefan Hajnoczi [Thu, 20 Jun 2019 17:37:08 +0000 (18:37 +0100)]
qdev: add qdev_add_vm_change_state_handler()
Children sometimes depend on their parent's vm change state handler
having completed. Add a vm change state handler API for devices that
guarantees tree depth ordering.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
* remotes/pmaydell/tags/pull-target-arm-20190708:
target/arm/vfp_helper: Call set_fpscr_to_host before updating to FPSCR
hw/arm/sbsa-ref: Remove unnecessary check for secure_sysmem == NULL
tests/migration-test: Fix read off end of aarch64_kernel array
target/arm: Fix sve_zcr_len_for_el
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
target/arm/vfp_helper: Call set_fpscr_to_host before updating to FPSCR
In commit e9d652824b0 we extracted the vfp_set_fpscr_to_host()
function but failed at calling it in the correct place, we call
it after xregs[ARM_VFP_FPSCR] is modified.
Fix by calling this function before we update FPSCR.
Peter Maydell [Mon, 8 Jul 2019 13:11:31 +0000 (14:11 +0100)]
hw/arm/sbsa-ref: Remove unnecessary check for secure_sysmem == NULL
In the virt machine, we support TrustZone being either present or
absent, and so the code must deal with the secure_sysmem pointer
possibly being NULL. In the sbsa-ref machine, TrustZone is always
present, but some code and comments copied from virt still treat
it as possibly not being present.
This causes Coverity to complain (CID 1407287) that we check
secure_sysmem for being NULL after an unconditional dereference.
Simplify the code so that instead of initializing the variable
to NULL, unconditionally assigning it, and then testing it for NULL,
we just initialize it correctly in the variable declaration and
then assume it to be non-NULL. We also delete a comment which
only applied to the non-TrustZone config.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190704142004.7150-1-peter.maydell@linaro.org Tested-by: Radosław Biernacki <radoslaw.biernacki@linaro.org> Reviewed-by: Radosław Biernacki <radoslaw.biernacki@linaro.org>
Peter Maydell [Mon, 8 Jul 2019 13:11:31 +0000 (14:11 +0100)]
tests/migration-test: Fix read off end of aarch64_kernel array
The test aarch64 kernel is in an array defined with
unsigned char aarch64_kernel[] = { [...] }
which means it could be any size; currently it's quite small.
However we write it to a file using init_bootfile(), which
writes exactly 512 bytes to the file. This will break if
we ever end up with a kernel larger than that, and will
read garbage off the end of the array in the current setup
where the kernel is smaller.
Make init_bootfile() take an argument giving the length of
the data to write. This allows us to use it for all architectures
(previously s390 had a special-purpose init_bootfile_s390x
which hardcoded the file to write so it could write the
correct length). We assert that the x86 bootfile really is
exactly 512 bytes as it should be (and as we were previously
just assuming it was).
This was detected by the clang-7 asan:
==15607==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55a796f51d20 at pc 0x55a796b89c2f bp 0x7ffc58e89160 sp 0x7ffc58e88908
READ of size 512 at 0x55a796f51d20 thread T0
#0 0x55a796b89c2e in fwrite (/home/petmay01/linaro/qemu-from-laptop/qemu/build/sanitizers/tests/migration-test+0xb0c2e)
#1 0x55a796c46492 in init_bootfile /home/petmay01/linaro/qemu-from-laptop/qemu/tests/migration-test.c:99:5
#2 0x55a796c46492 in test_migrate_start /home/petmay01/linaro/qemu-from-laptop/qemu/tests/migration-test.c:593
#3 0x55a796c44101 in test_baddest /home/petmay01/linaro/qemu-from-laptop/qemu/tests/migration-test.c:854:9
#4 0x7f906ffd3cc9 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x72cc9)
#5 0x7f906ffd3bfa (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x72bfa)
#6 0x7f906ffd3bfa (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x72bfa)
#7 0x7f906ffd3ea1 in g_test_run_suite (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x72ea1)
#8 0x7f906ffd3ec0 in g_test_run (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x72ec0)
#9 0x55a796c43707 in main /home/petmay01/linaro/qemu-from-laptop/qemu/tests/migration-test.c:1187:11
#10 0x7f906e9abb96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
#11 0x55a796b6c2d9 in _start (/home/petmay01/linaro/qemu-from-laptop/qemu/build/sanitizers/tests/migration-test+0x932d9)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20190702150311.20467-1-peter.maydell@linaro.org
Off by one error in the EL2 and EL3 tests. Remove the test
against EL3 entirely, since it must always be true.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20190702104732.31154-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* remotes/bonzini/tags/for-upstream:
ioapic: use irq number instead of vector in ioapic_eoi_broadcast
hw/i386: Fix linker error when ISAPC is disabled
Makefile: generate header file with the list of devices enabled
target/i386: kvm: Fix when nested state is needed for migration
minikconf: do not include variables from MINIKCONF_ARGS in config-all-devices.mak
target/i386: fix feature check in hyperv-stub.c
ioapic: clear irq_eoi when updating the ioapic redirect table entry
intel_iommu: Fix unexpected unmaps during global unmap
intel_iommu: Fix incorrect "end" for vtd_address_space_unmap
i386/kvm: Fix build with -m32
checkpatch: do not warn for multiline parenthesized returned value
pc: fix possible NULL pointer dereference in pc_machine_get_device_memory_region_size()
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Mon, 8 Jul 2019 08:46:19 +0000 (09:46 +0100)]
Merge remote-tracking branch 'remotes/ehabkost/tags/machine-next-pull-request' into staging
Machine and x86 queue, 2019-07-05
* CPU die topology support (Like Xu)
* Deprecation of features (Igor Mammedov):
* 'mem' parameter of '-numa node' option
* implict memory distribution between NUMA nodes
* deprecate -mem-path fallback to anonymous RAM
* x86 versioned CPU models (Eduardo Habkost)
* SnowRidge CPU model (Paul Lai)
* Add deprecation information to query-machines (Eduardo Habkost)
* Other i386 fixes
* remotes/ehabkost/tags/machine-next-pull-request: (42 commits)
tests: use -numa memdev option in tests instead of legacy 'mem' option
numa: allow memory-less nodes when using memdev as backend
numa: Make deprecation warnings conditional on !qtest_enabled()
i386: Add Cascadelake-Server-v2 CPU model
docs: Deprecate CPU model runnability guarantees
i386: Make unversioned CPU models be aliases
i386: Replace -noTSX, -IBRS, -IBPB CPU models with aliases
i386: Define -IBRS, -noTSX, -IBRS versions of CPU models
i386: Register versioned CPU models
i386: Get model-id from CPU object on "-cpu help"
i386: Add x-force-features option for testing
qmp: Add "alias-of" field to query-cpu-definitions
i386: Introduce SnowRidge CPU model
qmp: Add deprecation information to query-machines
vl.c: Add -smp, dies=* command line support and update doc
machine: Refactor smp_parse() in vl.c as MachineClass::smp_parse()
target/i386: Add CPUID.1F generation support for multi-dies PCMachine
i386: Remove unused host_cpudef variable
x86/cpu: use FeatureWordArray to define filtered_features
i386: make 'hv-spinlocks' a regular uint32 property
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(qemu) /home/test/qemu5/qemu/hw/intc/ioapic.c:266:27: runtime error: index 35 out of bounds for type 'int [24]'
=================================================================
==113504==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b000003114 at pc 0x5579e3c7a80f bp 0x7fd004bf8c10 sp 0x7fd004bf8c00
WRITE of size 4 at 0x61b000003114 thread T4
#0 0x5579e3c7a80e in ioapic_eoi_broadcast /home/test/qemu5/qemu/hw/intc/ioapic.c:266
#1 0x5579e3c6f480 in apic_eoi /home/test/qemu5/qemu/hw/intc/apic.c:428
#2 0x5579e3c720a7 in apic_mem_write /home/test/qemu5/qemu/hw/intc/apic.c:802
#3 0x5579e3b1e31a in memory_region_write_accessor /home/test/qemu5/qemu/memory.c:503
#4 0x5579e3b1e6a2 in access_with_adjusted_size /home/test/qemu5/qemu/memory.c:569
#5 0x5579e3b28d77 in memory_region_dispatch_write /home/test/qemu5/qemu/memory.c:1497
#6 0x5579e3a1b36b in flatview_write_continue /home/test/qemu5/qemu/exec.c:3323
#7 0x5579e3a1b633 in flatview_write /home/test/qemu5/qemu/exec.c:3362
#8 0x5579e3a1bcb1 in address_space_write /home/test/qemu5/qemu/exec.c:3452
#9 0x5579e3a1bd03 in address_space_rw /home/test/qemu5/qemu/exec.c:3463
#10 0x5579e3b8b979 in kvm_cpu_exec /home/test/qemu5/qemu/accel/kvm/kvm-all.c:2045
#11 0x5579e3ae4499 in qemu_kvm_cpu_thread_fn /home/test/qemu5/qemu/cpus.c:1287
#12 0x5579e4cbdb9f in qemu_thread_start util/qemu-thread-posix.c:502
#13 0x7fd0146376da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
#14 0x7fd01436088e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x12188e
This is because in ioapic_eoi_broadcast function, we uses 'vector' to
index the 's->irq_eoi'. To fix this, we should uses the irq number.
Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20190622002119.126834-1-liq3ea@163.com>
Julio Montes [Fri, 5 Jul 2019 14:35:54 +0000 (14:35 +0000)]
hw/i386: Fix linker error when ISAPC is disabled
v2: include config-devices.h to use CONFIG_IDE_ISA
Message-Id: <20190705143554.10295-2-julio.montes@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Julio Montes <julio.montes@intel.com>
Julio Montes [Fri, 5 Jul 2019 14:35:53 +0000 (14:35 +0000)]
Makefile: generate header file with the list of devices enabled
v2: generate config-devices.h which contains the list of devices enabled
Message-Id: <20190705143554.10295-1-julio.montes@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Julio Montes <julio.montes@intel.com>
Liran Alon [Mon, 24 Jun 2019 23:05:14 +0000 (02:05 +0300)]
target/i386: kvm: Fix when nested state is needed for migration
When vCPU is in VMX operation and enters SMM mode,
it temporarily exits VMX operation but KVM maintained nested-state
still stores the VMXON region physical address, i.e. even when the
vCPU is in SMM mode then (nested_state->hdr.vmx.vmxon_pa != -1ull).
Therefore, there is no need to explicitly check for
KVM_STATE_NESTED_SMM_VMXON to determine if it is necessary
to save nested-state as part of migration stream.
Reviewed-by: Karl Heubaum <karl.heubaum@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20190624230514.53326-1-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Mon, 24 Jun 2019 18:18:46 +0000 (20:18 +0200)]
minikconf: do not include variables from MINIKCONF_ARGS in config-all-devices.mak
When minikconf writes config-devices.mak, it includes all variables including
those from MINIKCONF_ARGS. This causes values from config-host.mak to "stick" to
the ones used in generating config-devices.mak, because config-devices.mak is
included after config-host.mak. Avoid this by omitting assignments coming
from the command line in the output of minikconf.
Reported-by: Christophe de Dinechin <dinechin@redhat.com> Reviewed-by: Christophe de Dinechin <dinechin@redhat.com> Tested-by: Christophe de Dinechin <dinechin@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The reason was the conversion of cpu->hyperv_synic to
cpu->hyperv_synic_kvm_only although the rest of the patch introduces a
feature checking mechanism. So I've fixed the KVM_EXIT_HYPERV_SYNIC in
hyperv-stub to do the same feature check as in the real hyperv.c
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Roman Kagan <rkagan@virtuozzo.com>
Message-Id: <20190624123835.28869-1-alex.bennee@linaro.org> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Li Qiang [Mon, 24 Jun 2019 15:16:35 +0000 (08:16 -0700)]
ioapic: clear irq_eoi when updating the ioapic redirect table entry
irq_eoi is used to count the number of irq injected during eoi
broadcast. It should be set to 0 when updating the ioapic's redirect
table entry.
Suggested-by: Peter Xu <peterx@redhat.com> Signed-off-by: Li Qiang <liq3ea@163.com> Reviewed-by: Peter Xu <peterx@redhat.com>
Message-Id: <20190624151635.22494-1-liq3ea@163.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
vtd_address_space_unmap() will do proper page mask alignment to make
sure each IOTLB message will have correct masks for notification
messages (2^N-1), but sometimes it can be expanded to even supercede
the registered range. That could lead to unexpected UNMAP of already
mapped regions in some other notifiers.
Instead of doing mindless expension of the start address and address
mask, we split the range into smaller ones and guarantee that each
small range will have correct masks (2^N-1) and at the same time we
should also try our best to generate as less IOTLB messages as
possible.
Reported-by: Yan Zhao <yan.y.zhao@intel.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Yan Zhao <yan.y.zhao@intel.com>
Message-Id: <20190624091811.30412-3-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Yan Zhao [Mon, 24 Jun 2019 09:18:10 +0000 (17:18 +0800)]
intel_iommu: Fix incorrect "end" for vtd_address_space_unmap
IOMMUNotifier is with inclusive ranges, so we should check
against (VTD_ADDRESS_SIZE(s->aw_bits) - 1).
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
[peterx: split from another bigger patch] Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <20190624091811.30412-2-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Max Reitz [Mon, 24 Jun 2019 19:39:13 +0000 (21:39 +0200)]
i386/kvm: Fix build with -m32
find_next_bit() takes a pointer of type "const unsigned long *", but the
first argument passed here is a "uint64_t *". These types are
incompatible when compiling qemu with -m32.
Just use ctz64() instead.
Fixes: c686193072a47032d83cb4e131dc49ae30f9e5d Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190624193913.28343-1-mreitz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Fri, 21 Jun 2019 11:28:54 +0000 (13:28 +0200)]
checkpatch: do not warn for multiline parenthesized returned value
While indeed we do not want to have
return (a);
it is less clear that this applies to
return (a &&
b);
Some editors indent more nicely if you have parentheses, and some people's
eyes may appreciate that as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <1561116534-21814-1-git-send-email-pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Igor Mammedov [Mon, 10 Jun 2019 13:50:35 +0000 (15:50 +0200)]
pc: fix possible NULL pointer dereference in pc_machine_get_device_memory_region_size()
QEMU will crash when device-memory-region-size property is read if ms->device_memory
wasn't initialized yet.
Crash can be reproduced with:
$QEMU -preconfig -qmp unix:qmp_socket,server,nowait &
./scripts/qmp/qom-get -s qmp_socket /machine.device-memory-region-size
Instead of crashing return 0 if ms->device_memory hasn't been initialized.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1560174635-22602-1-git-send-email-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Igor Mammedov [Tue, 2 Jul 2019 14:07:44 +0000 (10:07 -0400)]
numa: allow memory-less nodes when using memdev as backend
QEMU fails to start if memory-less node is present when memdev
is used
qemu-system-x86_64 -object memory-backend-ram,id=ram0,size=128M \
-numa node -numa node,memdev=ram0
with error:
"memdev option must be specified for either all or no nodes"
which works as expected if legacy 'mem' is used.
Fix check to make memory-less nodes valid when memdev option is used
but still disallow mix of mem and memdev options.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20190702140745.27767-2-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
numa: Make deprecation warnings conditional on !qtest_enabled()
This will help us avoid spurious warnings during "make check".
Note that this will silence the warnings generated by
tests/numa-test, but not the ones generated by
tests/bios-tables-test. We still need to change
tests/bios-tables-test to use "-numa ...,memdev=" to silence
these warnings.
Eduardo Habkost [Fri, 28 Jun 2019 00:28:44 +0000 (21:28 -0300)]
i386: Add Cascadelake-Server-v2 CPU model
Add new version of Cascadelake-Server CPU model, setting
stepping=5 and enabling the IA32_ARCH_CAPABILITIES MSR
with some flags.
The new feature will introduce a new host software requirement,
breaking our CPU model runnability promises. This means we can't
enable the new CPU model version by default in QEMU 4.1, because
management software isn't ready yet to resolve CPU model aliases.
This is why "pc-*-4.1" will keep returning Cascadelake-Server-v1
if "-cpu Cascadelake-Server" is specified.
Includes a test case to ensure the right combinations of
machine-type + CPU model + command-line feature flags will work
as expected.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190628002844.24894-10-ehabkost@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190703221723.8161-1-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Eduardo Habkost [Fri, 28 Jun 2019 00:28:42 +0000 (21:28 -0300)]
i386: Make unversioned CPU models be aliases
This will make unversioned CPU models behavior depend on the
machine type:
* "pc-*-4.0" and older will not report them as aliases.
This is done to keep compatibility with older QEMU versions
after management software starts translating aliases.
* "pc-*-4.1" will translate unversioned CPU models to -v1.
This is done to keep compatibility with existing management
software, that still relies on CPU model runnability promises.
* "none" will translate unversioned CPU models to their latest
version. This is planned become the default in future machine
types (probably in pc-*-4.3).
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190628002844.24894-8-ehabkost@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Eduardo Habkost [Fri, 28 Jun 2019 00:28:39 +0000 (21:28 -0300)]
i386: Register versioned CPU models
Add support for registration of multiple versions of CPU models.
The existing CPU models will be registered with a "-v1" suffix.
The -noTSX, -IBRS, and -IBPB CPU model variants will become
versions of the original models in a separate patch, so
make sure we register no versions for them.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190628002844.24894-5-ehabkost@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Eduardo Habkost [Fri, 28 Jun 2019 00:28:38 +0000 (21:28 -0300)]
i386: Get model-id from CPU object on "-cpu help"
When introducing versioned CPU models, the string at
X86CPUDefinition::model_id might not be the model-id we'll really
use. Instantiate a CPU object and check the model-id property on
"-cpu help"
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190628002844.24894-4-ehabkost@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Eduardo Habkost [Fri, 28 Jun 2019 00:28:37 +0000 (21:28 -0300)]
i386: Add x-force-features option for testing
Add a new option that can be used to disable feature flag
filtering. This will allow CPU model compatibility test cases to
work without host hardware dependencies.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190628002844.24894-3-ehabkost@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Paul Lai [Wed, 26 Jun 2019 16:21:29 +0000 (09:21 -0700)]
i386: Introduce SnowRidge CPU model
SnowRidge CPU supports Accelerator Infrastrcture Architecture (MOVDIRI,
MOVDIR64B), CLDEMOTE and SPLIT_LOCK_DISABLE.
MOVDIRI, MOVDIR64B, and CLDEMOTE are found via CPUID.
The availability of SPLIT_LOCK_DISABLE is check via msr access
References can be found in either:
https://software.intel.com/en-us/articles/intel-sdm
https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-and-future-features-programming-reference
Signed-off-by: Paul Lai <paul.c.lai@intel.com> Tested-by: Tao3 Xu <tao3.xu@intel.com>
Message-Id: <20190626162129.25345-1-paul.c.lai@intel.com>
[ehabkost: squashed SPLIT_LOCK_DETECT patch]
Message-Id: <20190626163232.25711-1-paul.c.lai@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Eduardo Habkost [Sat, 8 Jun 2019 23:34:47 +0000 (20:34 -0300)]
qmp: Add deprecation information to query-machines
Export machine type deprecation status through the query-machines
QMP command. With this, libvirt and management software will be
able to show this information to users and/or suggest changes to
VM configuration to avoid deprecated machines.
Like Xu [Thu, 20 Jun 2019 05:45:25 +0000 (13:45 +0800)]
vl.c: Add -smp, dies=* command line support and update doc
For PC target, users could configure the number of dies per one package
via command line with this patch, such as "-smp dies=2,cores=4".
The parsing rules of new cpu-topology model obey the same restrictions/logic
as the legacy socket/core/thread model especially on missing values computing.
Signed-off-by: Like Xu <like.xu@linux.intel.com>
Message-Id: <20190620054525.37188-4-like.xu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Thu, 20 Jun 2019 05:45:24 +0000 (13:45 +0800)]
machine: Refactor smp_parse() in vl.c as MachineClass::smp_parse()
To make smp_parse() more flexible and expansive, a smp_parse function
pointer is added to MachineClass that machine types could override.
The generic smp_parse() code in vl.c is moved to hw/core/machine.c, and
become the default implementation of MachineClass::smp_parse. A PC-specific
function called pc_smp_parse() has been added to hw/i386/pc.c, which in
this patch changes nothing against the default one .
Like Xu [Thu, 20 Jun 2019 05:45:23 +0000 (13:45 +0800)]
target/i386: Add CPUID.1F generation support for multi-dies PCMachine
The CPUID.1F as Intel V2 Extended Topology Enumeration Leaf would be
exposed if guests want to emulate multiple software-visible die within
each package. Per Intel's SDM, the 0x1f is a superset of 0xb, thus they
can be generated by almost same code as 0xb except die_offset setting.
If the number of dies per package is greater than 1, the cpuid_min_level
would be adjusted to 0x1f regardless of whether the host supports CPUID.1F.
Likewise, the CPUID.1F wouldn't be exposed if env->nr_dies < 2.
Roman Kagan [Tue, 18 Jun 2019 11:07:06 +0000 (11:07 +0000)]
i386: make 'hv-spinlocks' a regular uint32 property
X86CPU.hv-spinlocks is a uint32 property that has a special setter
validating the value to be no less than 0xFFF and no bigger than
UINT_MAX. The latter check is redundant; as for the former, there
appears to be no reason to prohibit the user from setting it to a lower
value.
So nuke the dedicated getter/setter pair and convert 'hv-spinlocks' to a
regular uint32 property.
Eduardo Habkost [Sat, 15 Jun 2019 20:05:05 +0000 (17:05 -0300)]
i386: Fix signedness of hyperv_spinlock_attempts
The current default value for hv-spinlocks is 0xFFFFFFFF (meaning
"never retry"). However, the value is stored as a signed
integer, making the getter of the hv-spinlocks QOM property
return -1 instead of 0xFFFFFFFF.
Fix this by changing the type of X86CPU::hyperv_spinlock_attempts
to uint32_t. This has no visible effect to guest operating
systems, affecting just the behavior of the QOM getter.
Eduardo Habkost [Tue, 11 Jun 2019 20:54:20 +0000 (17:54 -0300)]
i386: Don't print warning if phys-bits was set automatically
If cpu->host_phys_bits_limit is set, QEMU will make
cpu->phys_bits be lower than host_phys_bits on some cases. This
triggers a warning that was supposed to be printed only if
phys-bits was explicitly set in the command-line.
Reorder the code so the value of cpu->phys_bits is validated
before the cpu->host_phys_bits handling. This will avoid
unexpected warnings when cpu->host_phys_bits_limit is set.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190611205420.20286-1-ehabkost@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Igor Mammedov [Wed, 26 Jun 2019 07:42:28 +0000 (03:42 -0400)]
deprecate -mem-path fallback to anonymous RAM
Fallback might affect guest or worse whole host performance
or functionality if backing file were used to share guest RAM
with another process.
Patch deprecates fallback so that we could remove it in future
and ensure that QEMU will provide expected behavior and fail if
it can't use user provided backing file.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20190626074228.11558-1-imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Igor Mammedov [Thu, 30 May 2019 08:33:19 +0000 (10:33 +0200)]
numa: deprecate implict memory distribution between nodes
Implicit RAM distribution between nodes has exactly the same issues as:
"numa: deprecate 'mem' parameter of '-numa node' option"
only with QEMU being the user that's 'adding' 'mem' parameter.
Deprecate it, to get it out of the way so that we could consolidate
guest RAM allocation using memory backends making it consistent and
possibly later on transition to using memory devices instead of
adhoc memory mapping for the initial RAM.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1559205199-233510-4-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Igor Mammedov [Thu, 30 May 2019 08:33:18 +0000 (10:33 +0200)]
numa: deprecate 'mem' parameter of '-numa node' option
The parameter allows to configure fake NUMA topology where guest
VM simulates NUMA topology but not actually getting performance
benefits from it. The same or better results could be achieved
using 'memdev' parameter.
Beside of unpredictable performance, '-numa node.mem' option has
other issues when it's used with combination of -mem-path +
+ -mem-prealloc + memdev backends (pc-dimm), breaking binding of
memdev backends since mem-path/mem-prealloc are global and affect
the most of RAM allocations.
It's possible to make memdevs and global -mem-path/mem-prealloc
to play nicely together but that will just complicate already
complicated code and add unobious ways it could break on 2
different memmory allocation pathes and their combinations.
Instead of it, consolidate all guest RAM allocation over memdev
which still allows to create fake NUMA configurations if desired
and leaves one simplifyed code path to consider when it comes
to guest RAM allocation.
To achieve desired simplification deprecate 'mem' parameter as its
ad-hoc partitioning of initial RAM MemoryRegion can't be translated
to memdev based backend transparently to users and in compatible
manner (migration wise).
Later down the road that will allow to consolidate means of how
guest RAM is allocated and would permit us to clean up quite
a bit memory allocations and numa code, leaving only 'memdev'
implementation in place.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1559205199-233510-3-git-send-email-imammedo@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Igor Mammedov [Mon, 10 Jun 2019 13:10:07 +0000 (15:10 +0200)]
machine: show if CLI option '-numa node,mem' is supported in QAPI schema
Legacy '-numa node,mem' option has a number of issues and mgmt often
defaults to it. Unfortunately it's no possible to replace it with
an alternative '-numa memdev' without breaking migration compatibility.
What's possible though is to deprecate it, keeping option working with
old machine types only.
In order to help users to find out if being deprecated CLI option
'-numa node,mem' is still supported by particular machine type, add new
"numa-mem-supported" property to output of query-machines.
"numa-mem-supported" is set to 'true' for machines that currently support
NUMA, but it will be flipped to 'false' later on, once deprecation period
expires and kept 'true' only for old machine types that used to support
the legacy option so it won't break existing configuration that are using
it.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1560172207-378962-1-git-send-email-imammedo@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Wed, 12 Jun 2019 08:40:59 +0000 (16:40 +0800)]
i386: Update new x86_apicid parsing rules with die_offset support
In new sockets/dies/cores/threads model, the apicid of logical cpu could
imply die level info of guest cpu topology thus x86_apicid_from_cpu_idx()
need to be refactored with #dies value, so does apicid_*_offset().
To keep semantic compatibility, the legacy pkg_offset which helps to
generate CPUIDs such as 0x3 for L3 cache should be mapping to die_offset.
Signed-off-by: Like Xu <like.xu@linux.intel.com>
Message-Id: <20190612084104.34984-5-like.xu@linux.intel.com>
[ehabkost: squash unit test patch]
Message-Id: <20190612084104.34984-6-like.xu@linux.intel.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Wed, 12 Jun 2019 08:40:58 +0000 (16:40 +0800)]
i386/cpu: Consolidate die-id validity in smp context
The field die_id (default as 0) and has_die_id are introduced to X86CPU.
Following the legacy smp check rules, the die_id validity is added to
the same contexts as leagcy smp variables such as hmp_hotpluggable_cpus(),
machine_set_cpu_numa_node(), cpu_slot_to_string() and pc_cpu_pre_plug().
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Like Xu <like.xu@linux.intel.com>
Message-Id: <20190612084104.34984-4-like.xu@linux.intel.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Wed, 12 Jun 2019 08:40:57 +0000 (16:40 +0800)]
hw/i386: Adjust nr_dies with configured smp_dies for PCMachine
To support multiple dies configuration on PCMachine, the best place to
set CPUX86State->nr_dies with requested PCMachineState->smp_dies is in
pc_new_cpu() and pc_cpu_pre_plug(). Refactoring pc_new_cpu() is applied
and redundant parameter "const char *typename" would be removed.
Like Xu [Wed, 12 Jun 2019 08:40:56 +0000 (16:40 +0800)]
i386: Add die-level cpu topology to x86CPU on PCMachine
The die-level as the first PC-specific cpu topology is added to the leagcy
cpu topology model, which has one die per package implicitly and only the
numbers of sockets/cores/threads are configurable.
In the new model with die-level support, the total number of logical
processors (including offline) on board will be calculated as:
#cpus = #sockets * #dies * #cores * #threads
and considering compatibility, the default value for #dies would be
initialized to one in x86_cpu_initfn() and pc_machine_initfn().
Like Xu [Sat, 18 May 2019 20:54:28 +0000 (04:54 +0800)]
vl.c: Replace smp global variables with smp machine properties
The global smp variables in vl.c are completely replaced with machine properties.
Form this commit, the smp_cpus/smp_cores/smp_threads/max_cpus are deprecated
and only machine properties within MachineState are fully applied and enabled.
Signed-off-by: Like Xu <like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20190518205428.90532-11-like.xu@linux.intel.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Sat, 18 May 2019 20:54:27 +0000 (04:54 +0800)]
hw: Replace global smp variables with MachineState for all remaining archs
The global smp variables in alpha/hppa/mips/openrisc/sparc*/xtensa codes
are replaced with smp properties from MachineState.
A local variable of the same name would be introduced in the declaration
phase if it's used widely in the context OR replace it on the spot if it's
only used once. No semantic changes.
Signed-off-by: Like Xu <like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20190518205428.90532-10-like.xu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Sat, 18 May 2019 20:54:26 +0000 (04:54 +0800)]
hw/arm: Replace global smp variables with machine smp properties
The global smp variables in arm are replaced with smp machine properties.
The init_cpus() and *_create_rpu() are refactored to pass MachineState.
A local variable of the same name would be introduced in the declaration
phase if it's used widely in the context OR replace it on the spot if it's
only used once. No semantic changes.
Signed-off-by: Like Xu <like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20190518205428.90532-9-like.xu@linux.intel.com>
[ehabkost: Fix hw/arm/sbsa-ref.c and hw/arm/aspeed.c] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Sat, 18 May 2019 20:54:25 +0000 (04:54 +0800)]
hw/i386: Replace global smp variables with machine smp properties
The global smp variables in i386 are replaced with smp machine properties.
To avoid calling qdev_get_machine() as much as possible, some related funtions
for acpi data generations are refactored. No semantic changes.
A local variable of the same name would be introduced in the declaration
phase if it's used widely in the context OR replace it on the spot if it's
only used once. No semantic changes.
Like Xu [Sat, 18 May 2019 20:54:24 +0000 (04:54 +0800)]
hw/s390x: Replace global smp variables with machine smp properties
The global smp variables in s390x are replaced with smp machine properties.
A local variable of the same name would be introduced in the declaration
phase if it's used widely in the context OR replace it on the spot if it's
only used once. No semantic changes.
Signed-off-by: Like Xu <like.xu@linux.intel.com>
Message-Id: <20190518205428.90532-7-like.xu@linux.intel.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
[ehabkost: fix build failure at VCPU_IRQ_BUF_SIZE] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
fixup! hw/s390x: Replace global smp variables with machine smp properties
Like Xu [Sat, 18 May 2019 20:54:23 +0000 (04:54 +0800)]
hw/riscv: Replace global smp variables with machine smp properties
The global smp variables in riscv are replaced with smp machine properties.
A local variable of the same name would be introduced in the declaration
phase if it's used widely in the context OR replace it on the spot if it's
only used once. No semantic changes.
Signed-off-by: Like Xu <like.xu@linux.intel.com>
Message-Id: <20190518205428.90532-6-like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
[ehabkost: fix spike_board_init()]
[ehabkost: fix riscv_sifive_e_soc_init()] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Sat, 18 May 2019 20:54:22 +0000 (04:54 +0800)]
hw/ppc: Replace global smp variables with machine smp properties
The global smp variables in ppc are replaced with smp machine properties.
A local variable of the same name would be introduced in the declaration
phase if it's used widely in the context OR replace it on the spot if it's
only used once. No semantic changes.
Signed-off-by: Like Xu <like.xu@linux.intel.com>
Message-Id: <20190518205428.90532-5-like.xu@linux.intel.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Sat, 18 May 2019 20:54:21 +0000 (04:54 +0800)]
general: Replace global smp variables with smp machine properties
Basically, the context could get the MachineState reference via call
chains or unrecommended qdev_get_machine() in !CONFIG_USER_ONLY mode.
A local variable of the same name would be introduced in the declaration
phase out of less effort OR replace it on the spot if it's only used
once in the context. No semantic changes.
Signed-off-by: Like Xu <like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20190518205428.90532-4-like.xu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Sat, 18 May 2019 20:54:20 +0000 (04:54 +0800)]
machine: Refactor smp-related call chains to pass MachineState
To get rid of the global smp_* variables we're currently using, it's recommended
to pass MachineState in the list of incoming parameters for functions that use
global smp variables, thus some redundant parameters are dropped. It's applied
for legacy smbios_*(), *_machine_reset(), hot_add_cpu() and mips *_create_cpu().
Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Like Xu <like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20190518205428.90532-3-like.xu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Like Xu [Sat, 18 May 2019 20:54:19 +0000 (04:54 +0800)]
hw/boards: Add struct CpuTopology to MachineState
The cpu topology property CpuTopology is added to the MachineState
and its members are initialized with the leagcy global smp variables.
From this commit, the code in the system emulation mode is supposed to
use cpu topology variables from MachineState instead of the global ones
defined in vl.c and there is no semantic change.
Suggested-by: Igor Mammedov <imammedo@redhat.com> Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Like Xu <like.xu@linux.intel.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20190518205428.90532-2-like.xu@linux.intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* remotes/kraxel/tags/vga-20190705-pull-request:
ati-vga: Fix setting offset together with pitch for r128pro
ati-vga: Fix reverse bit blts
ati-vga: Fix frame buffer endianness for big endian target
ati-vga: Improve readability of ati_2d_blt function
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 5 Jul 2019 10:21:29 +0000 (11:21 +0100)]
Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-next-050719-3' into staging
Various testing fixes:
- tests/vm updates and clean-ups
- tests/vm serial autobuild on host (-netbsd v3)
- ensure MacOS builds do "brew update"
- ensure we test --static user builds
- fix hyperv compile failure
- fix missing var warning for OpenBSD (v2)
This brings my testing back to green on all CI services. Please note
the BSD installs will throw out some warnings during the setup phase.
They shouldn't re-occur once the images are built. NetBSD has been
dropped for now given slow install issues.
# gpg: Signature made Fri 05 Jul 2019 11:15:21 BST
# gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44
# gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full]
# Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44
* remotes/stsquad/tags/pull-testing-next-050719-3:
migration: move port_attr inside CONFIG_LINUX
target/i386: fix feature check in hyperv-stub.c
Makefile: Rename the 'vm-test' target as 'vm-help'
.travis.yml: force a brew update for MacOS builds
.travis.yml: default the --disable-system build to --static
tests/vm: ubuntu.i386: apt proxy setup
tests/vm: fedora autoinstall, using serial console
tests/vm: freebsd autoinstall, using serial console
tests/vm: openbsd autoinstall, using serial console
tests/vm: serial console support helpers
tests/vm: add vm-boot-{ssh,serial}-<guest> targets
tests/vm: proper guest shutdown
tests/vm: run test builds on snapshot
tests/vm: use ssh with pty unconditionally
tests/vm: send proxy environment variables over ssh
tests/vm: add source repos on ubuntu.i386
tests/vm: pin ubuntu.i386 image
tests/vm: avoid image presence check and removal
tests/vm: avoid extra compressed image copy
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Fri, 5 Jul 2019 08:51:50 +0000 (09:51 +0100)]
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
virtio, pc, pci: features, fixes, cleanups
virtio-pmem support.
libvhost user mq support.
A bunch of fixes all over the place.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Thu 04 Jul 2019 22:00:49 BST
# gpg: using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream: (22 commits)
docs: avoid vhost-user-net specifics in multiqueue section
libvhost-user: implement VHOST_USER_PROTOCOL_F_MQ
libvhost-user: support many virtqueues
libvhost-user: add vmsg_set_reply_u64() helper
pc: Move compat_apic_id_mode variable to PCMachineClass
virtio: Don't change "started" flag on virtio_vmstate_change()
virtio: Make sure we get correct state of device on handle_aio_output()
virtio: Set "start_on_kick" on virtio_set_features()
virtio: Set "start_on_kick" for legacy devices
virtio: add "use-started" property
virtio-pci: fix missing device properties
pc: Support for virtio-pmem-pci
numa: Handle virtio-pmem in NUMA stats
hmp: Handle virtio-pmem when printing memory device infos
virtio-pci: Proxy for virtio-pmem
virtio-pmem: sync linux headers
virtio-pci: Allow to specify additional interfaces for the base type
virtio-pmem: add virtio device
pcie: minor cleanups for slot control/status
pcie: work around for racy guest init
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
ati-vga: Fix setting offset together with pitch for r128pro
Turns out my last fix to this broke one case for Rage 128 Pro so
revert that part of previous patch. This now fixes the remaining
rendering problems for MorphOS which now can produce picture with
-device ati-vga (although it may not be optimised yet and video
overlay emulation is still known to be missing).
The pixman library only supports blts with left to right, top to
bottom order but the ATI VGA engine can also do different directions.
Fix support for these via a temporary buffer for now. This fixes
rendering issues related to such blts (such as moving windows) but
some other glitches still remain.
Stefan Hajnoczi [Wed, 26 Jun 2019 07:48:15 +0000 (08:48 +0100)]
docs: avoid vhost-user-net specifics in multiqueue section
The "Multiple queue support" section makes references to vhost-user-net
"queue pairs". This is confusing for two reasons:
1. This actually applies to all device types, not just vhost-user-net.
2. VHOST_USER_GET_QUEUE_NUM returns the number of virtqueues, not the
number of queue pairs.
Reword the section so that the vhost-user-net specific part is relegated
to the very end: we acknowledge that vhost-user-net historically
automatically enabled the first queue pair.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190626074815.19994-5-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Stefan Hajnoczi [Wed, 26 Jun 2019 07:48:14 +0000 (08:48 +0100)]
libvhost-user: implement VHOST_USER_PROTOCOL_F_MQ
Existing vhost-user device backends, including vhost-user-scsi and
vhost-user-blk, support multiqueue but libvhost-user currently does not
advertise this.
VHOST_USER_PROTOCOL_F_MQ enables the VHOST_USER_GET_QUEUE_NUM request
needed for a vhost-user master to query the number of queues. For
example, QEMU's vhost-user-net master depends on
VHOST_USER_PROTOCOL_F_MQ for multiqueue.
If you're wondering how any device backend with more than one virtqueue
functions today, it's because device types with a fixed number of
virtqueues do not require querying the number of queues. Therefore the
vhost-user master for vhost-user-input with 2 virtqueues, for example,
doesn't actually depend on VHOST_USER_PROTOCOL_F_MQ. It just enables
virtqueues 0 and 1 without asking.
Let there be multiqueue!
Suggested-by: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190626074815.19994-4-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Stefan Hajnoczi [Wed, 26 Jun 2019 07:48:13 +0000 (08:48 +0100)]
libvhost-user: support many virtqueues
Currently libvhost-user is hardcoded to at most 8 virtqueues. The
device backend should decide the number of virtqueues, not
libvhost-user. This is important for multiqueue device backends where
the guest driver needs an accurate number of virtqueues.
This change breaks libvhost-user and libvhost-user-glib API stability.
There is no stability guarantee yet, so make this change now and update
all in-tree library users.
This patch touches up vhost-user-blk, vhost-user-gpu, vhost-user-input,
vhost-user-scsi, and vhost-user-bridge. If the device has a fixed
number of queues that exact number is used. Otherwise the previous
default of 8 virtqueues is used.
vu_init() and vug_init() can now fail if malloc() returns NULL. I
considered aborting with an error in libvhost-user but it should be safe
to instantiate new vhost-user instances at runtime without risk of
terminating the process. Therefore callers need to handle the vu_init()
failure now.
vhost-user-blk and vhost-user-scsi duplicate virtqueue index checks that
are already performed by libvhost-user. This code would need to be
modified to use max_queues but remove it completely instead since it's
redundant.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190626074815.19994-3-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Stefan Hajnoczi [Wed, 26 Jun 2019 07:48:12 +0000 (08:48 +0100)]
libvhost-user: add vmsg_set_reply_u64() helper
The VhostUserMsg request is reused as the reply by message processing
functions. This is risky since request fields may corrupt the reply if
the vhost-user message handler function forgets to re-initialize them.
Changing this practice would be very invasive but we can introduce a
helper function to make u64 payload replies safe. This also eliminates
code duplication in message processing functions.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190626074815.19994-2-stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Eduardo Habkost [Fri, 28 Jun 2019 20:02:27 +0000 (17:02 -0300)]
pc: Move compat_apic_id_mode variable to PCMachineClass
Replace the static variable with a PCMachineClass field. This
will help us eventually get rid of the pc_compat_*() init
functions.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190628200227.1053-1-ehabkost@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Xie Yongji [Wed, 26 Jun 2019 02:31:30 +0000 (10:31 +0800)]
virtio: Don't change "started" flag on virtio_vmstate_change()
We will call virtio_set_status() on virtio_vmstate_change().
The "started" flag should not be changed in this case. Otherwise,
we may get an incorrect value when we set "started" flag but
not set DRIVER_OK in source VM.
Signed-off-by: Xie Yongji <xieyongji@baidu.com>
Message-Id: <20190626023130.31315-6-xieyongji@baidu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Xie Yongji [Wed, 26 Jun 2019 02:31:29 +0000 (10:31 +0800)]
virtio: Make sure we get correct state of device on handle_aio_output()
We should set the flags: "start_on_kick" and "started" after we call
the kick functions (handle_aio_output() and handle_output()).
Signed-off-by: Xie Yongji <xieyongji@baidu.com>
Message-Id: <20190626023130.31315-5-xieyongji@baidu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Xie Yongji [Wed, 26 Jun 2019 02:31:28 +0000 (10:31 +0800)]
virtio: Set "start_on_kick" on virtio_set_features()
The guest feature is not set correctly on virtio_reset() and
virtio_init(). So we should not use it to set "start_on_kick" at that
point. This patch set "start_on_kick" on virtio_set_features() instead.
Fixes: badaf79cfdbd3 ("virtio: Introduce started flag to VirtioDevice") Signed-off-by: Xie Yongji <xieyongji@baidu.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <20190626023130.31315-4-xieyongji@baidu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Xie Yongji [Wed, 26 Jun 2019 02:31:27 +0000 (10:31 +0800)]
virtio: Set "start_on_kick" for legacy devices
Besides virtio 1.0 transitional devices, we should also
set "start_on_kick" flag for legacy devices (virtio 0.9).
Signed-off-by: Xie Yongji <xieyongji@baidu.com> Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <20190626023130.31315-3-xieyongji@baidu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Xie Yongji [Wed, 26 Jun 2019 02:31:26 +0000 (10:31 +0800)]
virtio: add "use-started" property
In order to avoid migration issues, we introduce a "use-started"
property to the base virtio device to indicate whether use
"started" flag or not. This property will be true by default and
set to false when machine type <= 4.0.
Suggested-by: Greg Kurz <groug@kaod.org> Signed-off-by: Xie Yongji <xieyongji@baidu.com>
Message-Id: <20190626023130.31315-2-xieyongji@baidu.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Since commit a4ee4c8baa37154 ("virtio: Helper for registering virtio
device types"), virtio-gpu-pci, virtio-vga, and virtio-crypto-pci lost
some properties: "ioeventfd" and "vectors". This may cause various
issues, such as failing migration or invalid properties.
Since those VirtioPCI devices do not have a base name, their class are
initialized with virtio_pci_generic_base_class_init(). However, if the
VirtioPCIDeviceTypeInfo provided a class_init which sets dc->props,
the properties were overwritten by virtio_pci_generic_class_init().
Instead, introduce an intermediary base-type to register the generic
properties.
Override the device hotplug handler to properly handle the memory device
part via virtio-pmem-pci callbacks from the machine hotplug handler and
forward to the actual PCI bus hotplug handler.
As PCI hotplug has not been properly factored out into hotplug handlers,
most magic is performed in the (un)realize functions. Also some PCI host
buses don't have a PCI hotplug handler at all yet, just to be sure that
we alway have a hotplug handler on x86, add a simple error check.
Unlocking virtio-pmem will unlock virtio-pmem-pci.
Signed-off-by: David Hildenbrand <david@redhat.com>
[ Disable virtio-pmem hotunplug ] Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
Message-Id: <20190619094907.10131-8-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Account the memory to node 0 for now. Once (if ever) virtio-pmem
supports NUMA, we can account it to the right node.
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190619094907.10131-7-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hmp: Handle virtio-pmem when printing memory device infos
Print the memory device info just like for PCDIMM/NVDIMM.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190619094907.10131-6-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Pankaj Gupta [Wed, 19 Jun 2019 09:49:04 +0000 (15:19 +0530)]
virtio-pci: Proxy for virtio-pmem
We need a proxy device for virtio-pmem, and this device has to be the
actual memory device so we can cleanly hotplug it.
Forward memory device class functions either to the actual device or use
properties of the virtio-pmem device to implement these in the proxy.
virtio-pmem will only be compiled for selected, supported architectures
(that can deal with virtio/pci devices being memory devices). An
architecture that is prepared for that can simply enable
CONFIG_VIRTIO_PMEM to make it work.
As not all architectures support memory devices (and CONFIG_VIRTIO_PMEM
will be enabled per supported architecture), we have to move the PCI proxy
to a separate file.
Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
[ split up patches, memory-device changes, move pci proxy] Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20190619094907.10131-5-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Pankaj Gupta [Wed, 19 Jun 2019 09:49:03 +0000 (15:19 +0530)]
virtio-pmem: sync linux headers
Add linux headers for virtio pmem. These are not yet upstream - include
them temporarily as merge window in which this is supposed to be is
coming up shortly. If virtio-pmem ends up not being merged
then this will be reverted and accordingly virtio-pmem dropped.
Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
Message-Id: <20190619094907.10131-4-pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The reason was the conversion of cpu->hyperv_synic to
cpu->hyperv_synic_kvm_only although the rest of the patch introduces a
feature checking mechanism. So I've fixed the KVM_EXIT_HYPERV_SYNIC in
hyperv-stub to do the same feature check as in the real hyperv.c
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Roman Kagan <rkagan@virtuozzo.com> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Alex Bennée [Mon, 17 Jun 2019 15:35:22 +0000 (16:35 +0100)]
.travis.yml: default the --disable-system build to --static
It's fairly common to build qemu-user binaries with --static linking
so the binary can be copied around without libraries. Enable --static
in the default qemu-user build to cover this.
There are other qemu-user builds that use dynamic linking so they
should catch any problems there.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
projects / mirror_qemu.git / log