Peter Maydell [Tue, 12 Sep 2017 18:13:52 +0000 (19:13 +0100)]
nvic: Implement AIRCR changes for v8M
The Application Interrupt and Reset Control Register has some changes
for v8M:
* new bits SYSRESETREQS, BFHFNMINS and PRIS: these all have
real state if the security extension is implemented and otherwise
are constant
* the PRIGROUP field is banked between security states
* non-secure code can be blocked from using the SYSRESET bit
to reset the system if SYSRESETREQS is set
Implement the new state and the changes to register read and write.
For the moment we ignore the effects of the secure PRIGROUP.
We will implement the effects of PRIS and BFHFNMIS later.
Peter Maydell [Tue, 12 Sep 2017 18:13:51 +0000 (19:13 +0100)]
nvic: Add cached vectpending_prio state
Instead of looking up the pending priority
in nvic_pending_prio(), cache it in a new state struct
field. The calculation of the pending priority given
the interrupt number is more complicated in v8M with
the security extension, so the caching will be worthwhile.
This changes nvic_pending_prio() from returning a full
(group + subpriority) priority value to returning a group
priority. This doesn't require changes to its callsites
because we use it only in comparisons of the form
execution_prio > nvic_pending_prio()
and execution priority is always a group priority, so
a test (exec prio > full prio) is true if and only if
(execprio > group_prio).
(Architecturally the expected comparison is with the
group priority for this sort of "would we preempt" test;
we were only doing a test with a full priority as an
optimisation to avoid the mask, which is possible
precisely because the two comparisons always give the
same answer.)
Peter Maydell [Tue, 12 Sep 2017 18:13:50 +0000 (19:13 +0100)]
nvic: Add cached vectpending_is_s_banked state
With banked exceptions, just the exception number in
s->vectpending is no longer sufficient to uniquely identify
the pending exception. Add a vectpending_is_s_banked bool
which is true if the exception is using the sec_vectors[]
array.
Peter Maydell [Thu, 21 Sep 2017 15:28:59 +0000 (16:28 +0100)]
nvic: Add banked exception states
For the v8M security extension, some exceptions must be banked
between security states. Add the new vecinfo array which holds
the state for the banked exceptions and migrate it if the
CPU the NVIC is attached to implements the security extension.
Peter Maydell [Tue, 12 Sep 2017 18:13:48 +0000 (19:13 +0100)]
target/arm: Implement MSR/MRS access to NS banked registers
In v8M the MSR and MRS instructions have extra register value
encodings to allow secure code to access the non-secure banked
version of various special registers.
(We don't implement the MSPLIM_NS or PSPLIM_NS aliases, because
we don't currently implement the stack limit registers at all.)
Peter Maydell [Thu, 21 Sep 2017 13:40:30 +0000 (14:40 +0100)]
Merge remote-tracking branch 'remotes/yongbok/tags/mips-20170921' into staging
MIPS patches 2017-09-21
Changes:
QOMify MIPS cpu
Improve macro parenthesization
# gpg: Signature made Thu 21 Sep 2017 13:50:37 BST
# gpg: using RSA key 0x2238EB86D5F797C2
# gpg: Good signature from "Yongbok Kim <[email protected]>"
# 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: 8600 4CF5 3415 A5D9 4CFA 2B5C 2238 EB86 D5F7 97C2
* remotes/yongbok/tags/mips-20170921:
mips: Improve macro parenthesization
mips: replace cpu_mips_init() with cpu_generic_init()
mips: MIPSCPU model subclasses
mips: call cpu_mips_realize_env() from mips_cpu_realizefn()
mips: split cpu_mips_realize_env() out of cpu_mips_init()
mips: introduce internal.h and cleanup cpu.h
mips: move hw/mips/cputimer.c to target/mips/
Eric Blake [Tue, 19 Sep 2017 14:13:07 +0000 (09:13 -0500)]
mips: Improve macro parenthesization
Although none of the existing macro call-sites were broken,
it's always better to write macros that properly parenthesize
arguments that can be complex expressions, so that the intended
order of operations is not broken.
Igor Mammedov [Wed, 20 Sep 2017 19:49:33 +0000 (16:49 -0300)]
mips: MIPSCPU model subclasses
Register separate QOM types for each mips cpu model,
so it would be possible to reuse generic CPU creation
routines.
Signed-off-by: Igor Mammedov <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
[PMD: use internal.h, use void* to hold cpu_def in MIPSCPUClass,
mark MIPSCPU abstract, address Eduardo Habkost review] Tested-by: James Hogan <[email protected]> Reviewed-by: Eduardo Habkost <[email protected]> Signed-off-by: Yongbok Kim <[email protected]>
mips: call cpu_mips_realize_env() from mips_cpu_realizefn()
This changes the order between cpu_mips_realize_env() and
cpu_exec_initfn(), but cpu_exec_initfn() don't have anything that
depends on cpu_mips_realize_env() being called first.
This timer is a required part of the MIPS32/MIPS64 System Control coprocessor
(CP0). Moving it with the other architecture related files will allow an opaque
use of CPUMIPSState* in the next commit (introduce "internal.h").
also remove it from 'user' targets, remove an unnecessary include.
Roger Pau Monne [Thu, 24 Aug 2017 15:07:03 +0000 (16:07 +0100)]
xen/pt: allow QEMU to request MSI unmasking at bind time
When a MSI interrupt is bound to a guest using
xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
left masked by default.
This causes problems with guests that first configure interrupts and
clean the per-entry MSIX table mask bit and afterwards enable MSIX
globally. In such scenario the Xen internal msixtbl handlers would not
detect the unmasking of MSIX entries because vectors are not yet
registered since MSIX is not enabled, and vectors would be left
masked.
Introduce a new flag in the gflags field to signal Xen whether a MSI
interrupt should be unmasked after being bound.
This also requires to track the mask register for MSI interrupts, so
QEMU can also notify to Xen whether the MSI interrupt should be bound
masked or unmasked
Olaf Hering [Fri, 28 Jul 2017 13:11:51 +0000 (15:11 +0200)]
xen-disk: use g_new0 to fix build
g_malloc0_n is available since glib-2.24. To allow build with older glib
versions use the generic g_new0, which is already used in many other
places in the code.
Fixes commit 3284fad728 ("xen-disk: add support for multi-page shared rings")
Peter Maydell [Wed, 20 Sep 2017 19:33:48 +0000 (20:33 +0100)]
Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging
These patches fix regressions in 2.10
# gpg: Signature made Wed 20 Sep 2017 07:51:07 BST
# gpg: using DSA key 0x02FC3AEB0101DBC2
# gpg: Good signature from "Greg Kurz <[email protected]>"
# gpg: aka "Greg Kurz <[email protected]>"
# gpg: aka "Greg Kurz <[email protected]>"
# gpg: aka "Gregory Kurz (Groug) <[email protected]>"
# gpg: aka "[jpeg image of size 3330]"
# 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: 2BD4 3B44 535E C0A7 9894 DBA2 02FC 3AEB 0101 DBC2
* remotes/gkurz/tags/for-upstream:
9pfs: check the size of transport buffer before marshaling
9pfs: fix name_to_path assertion in v9fs_complete_rename()
9pfs: fix readdir() for 9p2000.u
Peter Maydell [Wed, 20 Sep 2017 16:35:36 +0000 (17:35 +0100)]
Merge remote-tracking branch 'remotes/ehabkost/tags/machine-next-pull-request' into staging
Machine/CPU/NUMA queue, 2017-09-19
# gpg: Signature made Tue 19 Sep 2017 21:17:01 BST
# gpg: using RSA key 0x2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <[email protected]>"
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/machine-next-pull-request:
MAINTAINERS: Update git URLs for my trees
hw/acpi-build: Fix SRAT memory building in case of node 0 without RAM
NUMA: Replace MAX_NODES with nb_numa_nodes in for loop
numa: cpu: calculate/set default node-ids after all -numa CLI options are parsed
arm: drop intermediate cpu_model -> cpu type parsing and use cpu type directly
pc: use generic cpu_model parsing
vl.c: convert cpu_model to cpu type and set of global properties before machine_init()
cpu: make cpu_generic_init() abort QEMU on error
qom: cpus: split cpu_generic_init() on feature parsing and cpu creation parts
hostmem-file: Add "discard-data" option
osdep: Define QEMU_MADV_REMOVE
vl: Clean up user-creatable objects when exiting
Jan Dakinevich [Wed, 20 Sep 2017 06:48:52 +0000 (08:48 +0200)]
9pfs: check the size of transport buffer before marshaling
v9fs_do_readdir_with_stat() should check for a maximum buffer size
before an attempt to marshal gathered data. Otherwise, buffers assumed
as misconfigured and the transport would be broken.
The patch brings v9fs_do_readdir_with_stat() in conformity with
v9fs_do_readdir() behavior.
Jan Dakinevich [Wed, 20 Sep 2017 06:48:51 +0000 (08:48 +0200)]
9pfs: fix readdir() for 9p2000.u
If the client is using 9p2000.u, the following occurs:
$ cd ${virtfs_shared_dir}
$ mkdir -p a/b/c
$ ls a/b
ls: cannot access 'a/b/a': No such file or directory
ls: cannot access 'a/b/b': No such file or directory
a b c
instead of the expected:
$ ls a/b
c
This is a regression introduced by commit f57f5878578a;
local_name_to_path() now resolves ".." and "." in paths,
and v9fs_do_readdir_with_stat()->stat_to_v9stat() then
copies the basename of the resulting path to the response.
With the example above, this means that "." and ".." are
turned into "b" and "a" respectively...
stat_to_v9stat() currently assumes it is passed a full
canonicalized path and uses it to do two different things:
1) to pass it to v9fs_co_readlink() in case the file is a symbolic
link
2) to set the name field of the V9fsStat structure to the basename
part of the given path
It only has two users: v9fs_stat() and v9fs_do_readdir_with_stat().
v9fs_stat() really needs 1) and 2) to be performed since it starts
with the full canonicalized path stored in the fid. It is different
for v9fs_do_readdir_with_stat() though because the name we want to
put into the V9fsStat structure is the d_name field of the dirent
actually (ie, we want to keep the "." and ".." special names). So,
we only need 1) in this case.
This patch hence adds a basename argument to stat_to_v9stat(), to
be used to set the name field of the V9fsStat structure, and moves
the basename logic to v9fs_stat().
Signed-off-by: Jan Dakinevich <[email protected]>
(groug, renamed old name argument to path and updated changelog) Signed-off-by: Greg Kurz <[email protected]>
List the branches where I queue patches for Machine Core, NUMA,
Memory Backends, and X86. Update the NUMA section to list the
"machine-next" branch instead of "numa".
hw/acpi-build: Fix SRAT memory building in case of node 0 without RAM
Currently, Using the fisrt node without memory on the machine makes
QEMU unhappy. With this example command line:
... \
-m 1024M,slots=4,maxmem=32G \
-numa node,nodeid=0 \
-numa node,mem=1024M,nodeid=1 \
-numa node,nodeid=2 \
-numa node,nodeid=3 \
Guest reports "No NUMA configuration found" and the NUMA topology is
wrong.
This is because when QEMU builds ACPI SRAT, it regards node 0 as the
default node to deal with the memory hole(640K-1M). this means the
node0 must have some memory(>1M), but, actually it can have no
memory.
Fix this problem by cut out the 640K hole in the same way the PCI
4G hole does.
Dou Liyang [Tue, 22 Aug 2017 07:45:36 +0000 (15:45 +0800)]
NUMA: Replace MAX_NODES with nb_numa_nodes in for loop
In QEMU, the number of the NUMA nodes is determined by parse_numa_opts().
Then, QEMU uses it for iteration, for example:
for (i = 0; i < nb_numa_nodes; i++)
However, in memory_region_allocate_system_memory(), it uses MAX_NODES
not nb_numa_nodes.
So, replace MAX_NODES with nb_numa_nodes to keep code consistency and
reduce the loop times.
Igor Mammedov [Thu, 1 Jun 2017 10:53:28 +0000 (12:53 +0200)]
numa: cpu: calculate/set default node-ids after all -numa CLI options are parsed
Calculating default node-ids for CPUs in possible_cpu_arch_ids()
is rather fragile since defaults calculation uses nb_numa_nodes but
callback might be potentially called early before all -numa CLI
options are parsed, which would lead to cpus assigned only upto
nb_numa_nodes at the time possible_cpu_arch_ids() is called.
Issue was introduced by
(7c88e65 numa: mirror cpu to node mapping in MachineState::possible_cpus)
and for example CLI:
-smp 4 -numa node,cpus=0 -numa node
would set props.node-id in possible_cpus array for every non
explicitly mapped CPU to the first node.
Issue is not visible to guest nor to mgmt interface due to
1) implictly mapped cpus are forced to the first node in
case of partial mapping
2) in case of default mapping possible_cpu_arch_ids() is
called after all -numa options are parsed (resulting
in correct mapping).
However it's fragile to rely on late execution of
possible_cpu_arch_ids(), therefore add machine specific
callback that returns node-id for CPU and use it to calculate/
set defaults at machine_numa_finish_init() time when all -numa
options are parsed.
Peter Maydell [Tue, 19 Sep 2017 17:08:48 +0000 (18:08 +0100)]
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20170919-v2' into staging
Assorted s390x patches:
- introduce virtio-gpu-ccw, with virtio-gpu endian fixes
- lots of cleanup in the s390x code
- make device_add work for s390x cpus
- enable seccomp on s390x
- an ivshmem endian fix
- set the reserved DHCP client architecture id for netboot
- fixes in the css and pci support
* remotes/cohuck/tags/s390x-20170919-v2: (38 commits)
MAINTAINERS/s390x: add terminal3270.c
virtio-ccw: Create a virtio gpu device for the ccw bus
virtio-gpu: Handle endian conversion
s390x/ccw: create s390 phb for compat reasons as well
configure: Allow --enable-seccomp on s390x, too
virtio-ccw: remove stale comments on endianness
s390x: allow CPU hotplug in random core-id order
s390x: generate sclp cpu information from possible_cpus
s390x: get rid of cpu_s390x_create()
s390x: get rid of cpu_states and use possible_cpus instead
s390x: implement query-hotpluggable-cpus
s390x: CPU hot unplug via device_del cannot work for now
s390x: allow cpu hotplug via device_add
s390x: print CPU definitions in sorted order
target/s390x: rename next_cpu_id to next_core_id
target/s390x: use "core-id" for cpu number/address/id handling
target/s390x: set cpu->id for linux user when realizing
s390x: allow only 1 CPU with TCG
target/s390x: use program_interrupt() in per_check_exception()
target/s390x: use trigger_pgm_exception() in s390_cpu_handle_mmu_fault()
...
s390x/ccw: create s390 phb for compat reasons as well
d32bd032d8 ("s390x/ccw: create s390 phb conditionally") made
registering the s390 pci host bridge conditional on presense
of the zpci facility bit. Sadly, that breaks migration from
machines that did not use the cpu model (2.7 and previous).
Create the s390 phb for pre-cpu model machines as well: We can
tweak s390_has_feat() to always indicate the zpci facility bit
when no cpu model is available (on 2.7 and previous compat machines).
Thomas Huth [Thu, 14 Sep 2017 10:36:03 +0000 (12:36 +0200)]
configure: Allow --enable-seccomp on s390x, too
libseccomp supports s390x since version 2.3.0, and I was able to start
a VM with "-sandbox on" without any obvious problems by using this patch,
so it should be safe to allow --enable-seccomp on s390x nowadays, too.
Halil Pasic [Thu, 14 Sep 2017 10:55:35 +0000 (12:55 +0200)]
virtio-ccw: remove stale comments on endianness
We have two stale comments suggesting one should think about virtio
config space endianness a bit longer. We have just done that, and came to
the conclusion we are fine as is: it's the responsibility of the virtio
device and not of the transport (and that is how it works now). Putting
the responsibility into the transport isn't even possible, because the
transport would have to know about the config space layout of each
device.
SCLP correctly indicates the core-id aka. CPU address for each available
CPU.
As the core-id corresponds to cpu_index, also a newly created kvm vcpu
gets assigned this core-id as vcpu id. So SIGP in the kernel works
correctly (it uses the vcpu id to lookup the correct CPU).
So there should be nothing hindering us from hotplugging CPUs in random
core-id order.
This now makes sure that the output from "query-hotpluggable-cpus"
is completely true. Until now, a specific order is implicit. Performance
vice, hotplugging CPUs in non-sequential order might not be the best thing
to do, as VCPU lookup inside KVM might be a little slower. But that
doesn't hinder us from supporting it.
s390x: generate sclp cpu information from possible_cpus
This is the first step to allow hot plugging of CPUs in a non-sequential
order. If a cpu is available ("plugged") can directly be decided by
looking at the cpu state pointer.
This makes sure, that really only cpus attached to the machine are
reported.
Now that there is only one user of cpu_s390x_create() left, make cpu
creation look like on x86.
- Perform the model/properties split and checks in s390_init_cpus()
- Parse features only once without having to remember if already parsed
- Pass only the typename to s390x_new_cpu()
- Use the typename of an existing CPU for hotplug via cpu-add
s390x: CPU hot unplug via device_del cannot work for now
device_del on a CPU will currently do nothing. Let's emit an error
telling that this is will currently not work (there is no architecture
support on s390x). Error message copied from ppc.
(qemu) device_del cpu1
device_del cpu1
CPU hot unplug not supported on this machine
E.g. the following now works:
device_add host-s390-cpu,id=cpu1,core-id=1
The system will perform the same checks as when using cpu_add:
- If the core_id is already in use
- If the next sequential core_id isn't used
- If core-id >= max_cpu is specified
In addition, mixed CPU models are checked. E.g. if starting with
-cpu host and trying to hotplug "qemu-s390-cpu":
"Mixed CPU models are not supported on s390x."
target/s390x: use "core-id" for cpu number/address/id handling
Some time ago we discussed that using "id" as property name is not the
right thing to do, as it is a reserved property for other devices and
will not work with device_add.
Switch to the term "core-id" instead, and use it as an equivalent to
"CPU address" mentioned in the PoP. There is no such thing as cpu number,
so rename env.cpu_num to env.core_id. We use "core-id" as this is the
common term to use for device_add later on (x86 and ppc).
We can get rid of cpu->id now. Keep cpu_index and env->core_id in sync.
cpu_index was already implicitly used by e.g. cpu_exists(), so keeping
both in sync seems to be the right thing to do.
cpu_index will now no longer automatically get set via
cpu_exec_realizefn(). For now, we were lucky that both implicitly stayed
in sync.
Our new cpu property "core-id" can be a static property. Range checks can
be avoided by using the correct type and the "setting after realized"
check is done implicitly.
device_add will later need the reserved "id" property. Hotplugging a CPU
on s390x will then be: "device_add host-s390-cpu,id=cpu2,core-id=2".
Specifying more than 1 CPU (e.g. -smp 5) leads to SIGP errors (the
guest tries to bring these CPUs up but fails), because we don't support
multiple CPUs on s390x under TCG.
Let's bail out if more than 1 is specified, so we don't raise people's
hope.
Setting the client architecture DHCP option to 0x001f (s390 Basic) [1]
allows the DHCP server to return a s390-specific bootfile if wanted.
DHCP servers not configured for the option (or not yet recognizing the
option value) will continue to work as they have done before.
Halil Pasic [Fri, 8 Sep 2017 15:24:44 +0000 (17:24 +0200)]
s390x/css: fix NULL handling for CCW addresses
Back then in the time of df1fe5bb49 ("s390: Virtual channel subsystem
support.", 2013-01-24) -EIO used to map to a channel-program check (via
the default label of the switch statement). Then 2dc95b4cac
("s390x/3270: 3270 data stream handling", 2016-04-01) came along
and that changed dramatically.
Let us roll back this undesired side effect, and go back to
channel-program check.
Halil Pasic [Fri, 8 Sep 2017 15:24:43 +0000 (17:24 +0200)]
s390x/css: drop data-check in interpretation
The architecture says that channel-data check is indicating that
an uncorrected storage (memory) error has been detected in regard
to the data residing in main storage (memory) that is currently
used for an I/O operation. The described detection is done using
the CBC technology.
The ccw interpretation code is however generating a channel-data check
effectively when the (device specific) ccw_cb returns -EFAULT. In case
of virtio-ccw devices this happens when mapping memory fails, or when a
NULL pointer is encountered. So this behavior is not architecture
conform.
Furthermore the best fit for these situations (null pointer, mapping a
piece of guest memory fails) from architectural perspective the condition
described as the channel subsystem refers to a location that is not
available, which when encountered shall result in a channel-program
check.
To fix this, all we have to do is to get rid of the switch case matching
-EFAULT: the default is generating a channel-program check.
Thomas Huth [Wed, 30 Aug 2017 13:39:03 +0000 (15:39 +0200)]
hw/misc/ivshmem: Fix ivshmem_recv_msg() to also work on big endian systems
The "slow" ivshmem-tests currently fail when they are running on a
big endian host:
$ uname -m
ppc64
$ V=1 QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 tests/ivshmem-test -m slow
/x86_64/ivshmem/single: OK
/x86_64/ivshmem/hotplug: OK
/x86_64/ivshmem/memdev: OK
/x86_64/ivshmem/pair: OK
/x86_64/ivshmem/server-msi: qemu-system-x86_64:
-device ivshmem-doorbell,chardev=chr0,vectors=2: server sent invalid ID message
Broken pipe
The problem is that the server side code in ivshmem_server_send_one_msg()
correctly translates all messages IDs into little endian 64-bit values,
but the client side code in the ivshmem_recv_msg() function does not swap
the byte order back. Fix it by passing the value through le64_to_cpu().
Yi Min Zhao [Tue, 5 Sep 2017 10:13:00 +0000 (12:13 +0200)]
s390x/pci: add iommu replay callback
Let's introduce iommu replay callback for s390 pci iommu memory region.
Currently we don't need any dma mapping replay. So let it return
directly. This implementation will avoid meaningless loops calling
translation callback.
Yi Min Zhao [Tue, 5 Sep 2017 10:12:59 +0000 (12:12 +0200)]
s390x/pci: fixup ind_offset of msix routing entry
The guest uses the mpcifc instruction to register the aibvo of a zpci
device, which is the starting offset of indicators in the indicator
area and thus remains constant. Each msix vector is an offset from the
aibvo. When we map a msix route to an adapter route, we should not
modify the starting offset, but instead add the vector to the starting
offset to get the absolute offset in the specific route.
Yi Min Zhao [Tue, 5 Sep 2017 10:12:58 +0000 (12:12 +0200)]
s390x/pci: remove idx from msix msg data
PCIDevice pointer has been a parameter of kvm_arch_fixup_msi_route().
So we don't need to store zpci idx in msix message data to find out the
specific zpci device. Instead, we could use pci device id to find its
corresponding zpci device.
Thomas Huth [Thu, 31 Aug 2017 14:40:08 +0000 (16:40 +0200)]
tests: Enable the drive_del test also on s390x
We can use the drive_del test on s390x, too, to check that adding and
deleting also works fine with the virtio-ccw bus. But we have to make
sure that we use the devices with the "-ccw" suffix instead of the
"-pci" suffix for the virtio-ccw transport on s390x. Introduce a helper
function called qvirtio_get_dev_type() that returns the correct string
for the current architecture.
Halil Pasic [Thu, 31 Aug 2017 12:18:28 +0000 (14:18 +0200)]
s390x/css: fix cc handling for XSCH
The function ioinst_handle_xsch is presenting cc 2 when it's supposed to
present cc 1 and the other way around, because css_do_xsch has the error
codes mixed up. Because cc 1 has precedence over cc 2 we also have to
swap the two checks.
* remotes/bonzini/tags/for-upstream: (51 commits)
docker: fix creation of archives
default-configs: Replace $(and ...) with $(call land, ...)
osdep.h: Prohibit disabling assert() in supported builds
checkpatch: add hwaddr to @typeList
accel/hax: move hax-stub.c to accel/stubs/
target/i386: fix "info mem" for LA57 mode
scripts: let checkpatch.pl process an entire GIT branch
update-linux-headers: prepare for hyperv.h removal
hyperv: add header with protocol definitions
i386/cpu/hyperv: support over 64 vcpus for windows guests
Convert remaining single line fprintf() to warn_report()
Makefile: Remove libqemustub.a
ptimer-test: do not link to libqemustub.a/libqemuutil.a
target/mips: Convert VM clock update prints to warn_report
General warn report fixups
Convert multi-line fprintf() to warn_report()
Convert single line fprintf(.../n) to warn_report()
Convert remaining error_report() to warn_report()
hw/i386: Improve some of the warning messages
test-qga: add missing qemu-ga tool dependency
...
Thomas Huth [Mon, 18 Sep 2017 18:32:18 +0000 (20:32 +0200)]
default-configs: Replace $(and ...) with $(call land, ...)
Using $(and ...) is dangerous here: It only works as long as the first
argument is set to 'y' or completely unset. It does not work if the
first argument is set to 'n' for example. Let's use the "land" make
function instead which has been written explicitely for this purpose.
Eric Blake [Mon, 11 Sep 2017 21:13:20 +0000 (16:13 -0500)]
osdep.h: Prohibit disabling assert() in supported builds
We already have several files that knowingly require assert()
to work, sometimes because refactoring the code for proper
error handling has not been tackled yet; there are probably
other files that have a similar situation but with no comments
documenting the same. In fact, we have places in migration
that handle untrusted input with assertions, where disabling
the assertions risks a worse security hole than the current
behavior of losing the guest to SIGABRT when migration fails
because of the assertion. Promote our current per-file
safety-valve to instead be project-wide, and expand it to also
cover glib's g_assert().
Note that we do NOT want to encourage 'assert(side-effects);'
(that is a bad practice that prevents copy-and-paste of code to
other projects that CAN disable assertions; plus it costs
unnecessary reviewer mental cycles to remember whether a project
special-cases the crippling of asserts); and we would LIKE to
fix migration to not rely on asserts (but that takes a big code
audit). But in the meantime, we DO want to send a message
that anyone that disables assertions has to tweak code in order
to compile, making it obvious that they are taking on additional
risk that we are not going to support. At the same time, leave
comments mentioning NDEBUG in files that we know still need to
be scrubbed, so there is at least something to grep for.
It would be possible to come up with some other mechanism for
doing runtime checking by default, but which does not abort
the program on failure, while leaving side effects in place
(unlike how crippling assert() avoids even the side effects),
perhaps under the name q_verify(); but it was not deemed worth
the effort (developers should not have to learn a replacement
when the standard C macro works just fine, and it would be a lot
of churn for little gain). The patch specifically uses #error
rather than #warn so that a user is forced to tweak the header
to acknowledge the issue, even when not using a -Werror
compilation.
Greg Kurz [Thu, 14 Sep 2017 09:12:07 +0000 (11:12 +0200)]
checkpatch: add hwaddr to @typeList
The script doesn't know about all possible types and learn them as
it parses the code. If it reaches a line with a type cast but the
type isn't known yet, it is misinterpreted as an identifier.
For example the following line:
foo = (hwaddr) -1;
results in the following false-positive to be reported:
ERROR: spaces required around that '-' (ctx:VxV)
Let's add this standard QEMU type to the list of pre-known types.
scripts: let checkpatch.pl process an entire GIT branch
Currently before submitting a series, devs should run checkpatch.pl
across each patch to be submitted. This can be automated using a
command such as:
git rebase -i master -x 'git show | ./scripts/checkpatch.pl -'
This is rather long winded to type, so this patch introduces a way
to tell checkpatch.pl to validate a series of GIT revisions.
There are now three modes it can operate in 1) check a patch 2) check a source
file, or 3) check a git branch.
If no flags are given, the mode is determined by checking the args passed to
the command. If the args contain a literal ".." it is treated as a GIT revision
list. If the args end in ".patch" or equal "-" it is treated as a patch file.
Otherwise it is treated as a source file.
This automatic guessing can be overridden using --[no-]patch --[no-]file or
--[no-]branch
Roman Kagan [Thu, 13 Jul 2017 20:15:21 +0000 (23:15 +0300)]
hyperv: add header with protocol definitions
The definitions for Hyper-V emulation are currently taken from a header
imported from the Linux kernel.
However, as these describe a third-party protocol rather than a kernel
API, it probably wasn't a good idea to publish it in the kernel uapi.
This patch introduces a header that provides all the necessary
definitions, superseding the one coming from the kernel.
The new header supports (temporary) coexistence with the kernel one.
The constants explicitly named in the Hyper-V specification (e.g. msr
numbers) are defined in a non-conflicting way. Other constants and
types have got new names.
While at this, the protocol data structures are defined in a more
conventional way, without bitfields, enums, and excessive unions.
The code using this stuff is adjusted, too; it can now be built both
with and without the kernel header in the tree.
i386/cpu/hyperv: support over 64 vcpus for windows guests
Starting with Windows Server 2012 and Windows 8, if
CPUID.40000005.EAX contains a value of -1, Windows assumes specific
limit to the number of VPs. In this case, Windows Server 2012
guest VMs may use more than 64 VPs, up to the maximum supported
number of processors applicable to the specific Windows
version being used.
Alistair Francis [Fri, 18 Aug 2017 18:47:35 +0000 (11:47 -0700)]
Convert remaining single line fprintf() to warn_report()
Convert any remaining uses of fprintf(stderr, "warning:"...
to use warn_report() instead. This helps standardise on a single
method of printing warnings to the user.
All of the warnings were changed using this command:
find ./* -type f -exec sed -i 's|fprintf(.*".*warning[,:] |warn_report("|Ig' {} +
The #include lines and chagnes to the test Makefile were manually
updated to allow the code to compile.
Paolo Bonzini [Tue, 19 Sep 2017 14:20:31 +0000 (16:20 +0200)]
Makefile: Remove libqemustub.a
Using two libraries (libqemuutil.a and libqemustub.a) would sometimes
result in circular dependencies. To avoid these issues let's just
combine both into a single library that functions as both.
Alistair Francis [Mon, 11 Sep 2017 19:52:53 +0000 (12:52 -0700)]
Convert multi-line fprintf() to warn_report()
Convert all the multi-line uses of fprintf(stderr, "warning:"..."\n"...
to use warn_report() instead. This helps standardise on a single
method of printing warnings to the user.
All of the warnings were changed using these commands:
find ./* -type f -exec sed -i \
'N; {s|fprintf(.*".*warning[,:] \(.*\)\\n"\(.*\));|warn_report("\1"\2);|Ig}' \
{} +
find ./* -type f -exec sed -i \
'N;N; {s|fprintf(.*".*warning[,:] \(.*\)\\n"\(.*\));|warn_report("\1"\2);|Ig}' \
{} +
find ./* -type f -exec sed -i \
'N;N;N; {s|fprintf(.*".*warning[,:] \(.*\)\\n"\(.*\));|warn_report("\1"\2);|Ig}' \
{} +
find ./* -type f -exec sed -i \
'N;N;N;N {s|fprintf(.*".*warning[,:] \(.*\)\\n"\(.*\));|warn_report("\1"\2);|Ig}' \
{} +
find ./* -type f -exec sed -i \
'N;N;N;N;N {s|fprintf(.*".*warning[,:] \(.*\)\\n"\(.*\));|warn_report("\1"\2);|Ig}' \
{} +
find ./* -type f -exec sed -i \
'N;N;N;N;N;N {s|fprintf(.*".*warning[,:] \(.*\)\\n"\(.*\));|warn_report("\1"\2);|Ig}' \
{} +
find ./* -type f -exec sed -i \
'N;N;N;N;N;N;N; {s|fprintf(.*".*warning[,:] \(.*\)\\n"\(.*\));|warn_report("\1"\2);|Ig}' \
{} +
Indentation fixed up manually afterwards.
Some of the lines were manually edited to reduce the line length to below
80 charecters. Some of the lines with newlines in the middle of the
string were also manually edit to avoid checkpatch errrors.
The #include lines were manually updated to allow the code to compile.
Several of the warning messages can be improved after this patch, to
keep this patch mechanical this has been moved into a later patch.
Alistair Francis [Mon, 11 Sep 2017 19:52:50 +0000 (12:52 -0700)]
Convert single line fprintf(.../n) to warn_report()
Convert all the single line uses of fprintf(stderr, "warning:"..."\n"...
to use warn_report() instead. This helps standardise on a single
method of printing warnings to the user.
All of the warnings were changed using this command:
find ./* -type f -exec sed -i \
's|fprintf(.*".*warning[,:] \(.*\)\\n"\(.*\));|warn_report("\1"\2);|Ig' \
{} +
Some of the lines were manually edited to reduce the line length to below
80 charecters.
The #include lines were manually updated to allow the code to compile.
Alistair Francis [Mon, 11 Sep 2017 19:52:46 +0000 (12:52 -0700)]
Convert remaining error_report() to warn_report()
In a previous patch (3dc6f8693694a649a9c83f1e2746565b47683923) we
converted uses of error_report("warning:"... to use warn_report()
instead. This was to help standardise on a single method of printing
warnings to the user.
There appears to have been some cases that slipped through in patch sets
applied around the same time, this patch catches the few remaining
cases.
All of the warnings were changed using this command:
find ./* -type f -exec sed -i \
's|error_report(".*warning[,:] |warn_report("|Ig' {} +
kvm: kvm_log_sync() is only called with known memory sections
Flatview will make sure that we can only end up in this function with
memory sections that correspond to exactly one slot. So we don't
have to iterate multiple times. There won't be overlapping slots but
only matching slots.
Properly align the section and look up the corresponding slot. This
heavily simplifies this function.
We can now get rid of kvm_lookup_overlapping_slot().
kvm: we never have overlapping slots in kvm_set_phys_mem()
The way flatview handles memory sections, we will never have overlapping
memory sections in kvm.
address_space_update_topology_pass() will make sure that we will only
get called for
a) an existing memory section for which we only update parameters
(log_start, log_stop).
b) an existing memory section we want to delete (region_del)
c) a brand new memory section we want to add (region_add)
We cannot have overlapping memory sections in kvm as we will first remove
the overlapping sections and then add the ones without conflicts.
Therefore we can remove the complexity for handling prefix and suffix
slots.
We already require DESTROY_MEMORY_REGION_WORKS, JOIN_MEMORY_REGIONS_WORKS
was added just half a year later.
In addition, with flatview overlapping memory regions are first
removed before adding the changed one. So we can't really detect joining
memory regions this way.
While loading kernel via multiboot-v1 image, (flags & 0x00010000)
indicates that multiboot header contains valid addresses to load
the kernel image. These addresses are used to compute kernel
size and kernel text offset in the OS image. Validate these
address values to avoid an OOB access issue.
Ladi Prosek [Mon, 7 Aug 2017 08:57:03 +0000 (10:57 +0200)]
i386/kvm: advertise Hyper-V frequency MSRs
As of kernel commit eb82feea59d6 ("KVM: hyperv: support HV_X64_MSR_TSC_FREQUENCY
and HV_X64_MSR_APIC_FREQUENCY"), KVM supports two new MSRs which are required
for nested Hyper-V to read timestamps with RDTSC + TSC page.
This commit makes QEMU advertise the MSRs with CPUID.40000003H:EAX[11] and
CPUID.40000003H:EDX[8] as specified in the Hyper-V TLFS and experimentally
verified on a Hyper-V host. The feature is enabled with the existing hv-time CPU
flag, and only if the TSC frequency is stable across migrations and known.
projects / qemu.git / log