It is not necessary to munmap an area before remapping it with MAP_FIXED;
if the memory region specified by addr and len overlaps pages of any
existing mapping, then the overlapped part of the existing mapping will
be discarded.

On the other hand, if QEMU does munmap the pages, there is a small
probability that another mmap sneaks in and catches the just-freed
portion of the address space.  In effect, munmap followed by
mmap(MAP_FIXED) is a use-after-free error, and Coverity flags it
as such.  Fix it.
Reviewed-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Commit 0b183fc8:"memory: move mem_path handling to
memory_region_allocate_system_memory" split memory_region_init_ram and
memory_region_init_ram_from_file. Also it moved mem-path handling a step
up from memory_region_init_ram to memory_region_allocate_system_memory.

Therefore for any board that uses memory_region_init_ram directly,
-mem-path is not supported.

Fix this by replacing memory_region_init_ram with
memory_region_allocate_system_memory.
Signed-off-by: NDirk Mueller <dmueller@suse.com>
Message-Id: <CAL5wTH7o8uA59Ep0n41i0M19VFWa73n9m172j2W3fjz6=PSVBA@mail.gmail.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Commit 0b183fc8:"memory: move mem_path handling to
memory_region_allocate_system_memory" split memory_region_init_ram and
memory_region_init_ram_from_file. Also it moved mem-path handling a step
up from memory_region_init_ram to memory_region_allocate_system_memory.

Therefore for any board that uses memory_region_init_ram directly,
-mem-path is not supported.

Fix this by replacing memory_region_init_ram with
memory_region_allocate_system_memory.
Signed-off-by: NDirk Mueller <dmueller@suse.com>
Message-Id: <CAL5wTH4-=HJUvwBu+2o6jGanJesJOyNf3sL8-5+d_-6C3cWBfA@mail.gmail.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Acked-by: NLeon Alrae <leon.alrae@imgtec.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Commit 0b183fc8:"memory: move mem_path handling to
memory_region_allocate_system_memory" split memory_region_init_ram and
memory_region_init_ram_from_file. Also it moved mem-path handling a step
up from memory_region_init_ram to memory_region_allocate_system_memory.

Therefore for any board that uses memory_region_init_ram directly,
-mem-path is not supported.

Fix this by replacing memory_region_init_ram with
memory_region_allocate_system_memory.
Signed-off-by: NDirk Mueller <dmueller@suse.com>
Message-Id: <CAL5wTH6X-GsT1AA8kEtP_e7oZWGZgi=fCcDfSs3wLgJN30DbUw@mail.gmail.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <1427271528-11624-1-git-send-email-armbru@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

It is wrong to use address_space_memory directly, because there could be an
IOMMU in the middle.  Passing the entire PVSCSIRingInfo to RS_GET_FIELD
and RS_SET_FIELD makes it easy to go back to the PVSCSIState.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

It is wrong to use address_space_memory directly, because there could be an
IOMMU in the middle.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

following a4649824, it's now possible for
there to be attempts to take the BQL before CPUs have been realized in
cases where a machine model inits peripherals before the first CPU.

BQL lock aquisition kicks the first_cpu, leading to a segfault if this
happens pre-realize. Guard the CPU kick routine to perform no action for
a CPU that doesn't exist or doesn't have a thread yet.

There was a fix to this with commit
6b49809c, but the check there misses
the case where the CPU has been inited and not realized. Strengthen the
check to make sure that the first_cpu has a thread (i.e. it is
realized) before allowing the kick.
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-Id: <1427107689-6946-1-git-send-email-peter.crosthwaite@xilinx.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

If the guest programs a sufficiently large timeout value an integer
overflow can occur in i6300esb_restart_timer().  e.g. if the maximum
possible timer preload value of 0xfffff is programmed then we end up with
the calculation:

timeout = get_ticks_per_sec() * (0xfffff << 15) / 33000000;

get_ticks_per_sec() returns 1000000000 (10^9) giving:

     10^9 * (0xfffff * 2^15) == 0x1dcd632329b000000 (65 bits)

Obviously the division by 33MHz brings it back under 64-bits, but the
overflow has already occurred.

Since signed integer overflow has undefined behaviour in C, in theory this
could be arbitrarily bad.  In practice, the overflowed value wraps around
to something negative, causing the watchdog to immediately expire, killing
the guest, which is still fairly bad.

The bug can be triggered by running a Linux guest, loading the i6300esb
driver with parameter "heartbeat=2046" and opening /dev/watchdog.  The
watchdog will trigger as soon as the device is opened.

This patch corrects the problem by using muldiv64(), which effectively
allows a 128-bit intermediate value between the multiplication and
division.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Message-Id: <1427075508-12099-3-git-send-email-david@gibson.dropbear.id.au>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The IO operations for the i6300esb watchdog timer are marked as
DEVICE_NATIVE_ENDIAN.  This is not correct, and - as a PCI device - should
be DEVICE_LITTLE_ENDIAN.

This allows i6300esb to work on ppc targets (yes, using an Intel ICH
derived device on ppc is a bit odd, but the driver exists on the guest
and there's no more obviously suitable watchdog device).
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Message-Id: <1427075508-12099-2-git-send-email-david@gibson.dropbear.id.au>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The fw_cfg documentation says this of the revision key (0x0001, FW_CFG_ID):

> A 32-bit little-endian unsigned int, this item is used as an interface
> revision number, and is currently set to 1 by all QEMU architectures
> which expose a fw_cfg device.

arm/virt doesn't.  It could be argued that that's an error in
"hw/arm/virt.c"; on the other hand, all of the other fw_cfg providing
boards set the interface version to 1 manually, despite the device
coming from the same, shared implementation. Therefore, instead of
adding

    fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);

to arm/virt, consolidate all such existing calls in the fw_cfg
initialization code.
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Message-Id: <1426789244-26318-1-git-send-email-somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

32-bit PPC cannot do atomic operations on long long.  Inside the loops,
we are already using local counters that are summed at the end of
the run---with some exceptions (rcu_stress_count for rcutorture,
n_nodes for test-rcu-list): fix them to use the same technique.
For test-rcu-list, remove the mostly unused member "val" from the
list.  Then, use a mutex to protect the global counts.

Performance does not matter there because every thread will only enter
the critical section once.

Remaining uses of atomic instructions are for ints or pointers.
Reported-by: NAndreas Faerber <afaerber@suse.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

TriCore bugfixes for 2.3-rc1

# gpg: Signature made Tue Mar 24 08:48:33 2015 GMT using RSA key ID 6B69CA14
# gpg: Good signature from "Bastian Koppelmann <kbastian@mail.uni-paderborn.de>"

* remotes/bkoppelmann/tags/pull-tricore-20150324:
  target-tricore: properly fix dvinit_b/h_13
  target-tricore: fix RRPW_DEXTR using wrong reg
  target-tricore: fix DVINIT_HU/BU calculating overflow before result
  target-tricore: Fix two helper functions (clang warnings)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The TriCore documentation was wrong on how to calculate ovf bits for those two
instructions, which I confirmed with real hardware (TC1796 chip). An ovf
actually happens, if the result (without remainder) does not fit into 8/16 bits.
Signed-off-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>

RRPW_DEXTR used r1 for the low part and r2 for the high part. It should be the
other way round. This also fixes that the result of the first shift was not
saved in a temp and could overwrite registers that were needed for the second
shift.
Signed-off-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>

dvinit_hu/bu for ISA v1.3 calculate the higher part of the result, that is needed
for the overflow bits, after calculating the overflow bits.
Signed-off-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>

clang report:

target-tricore/op_helper.c:1247:24: warning:
  taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
  has no effect [-Wabsolute-value]
target-tricore/op_helper.c:1248:25: warning:
  taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
  has no effect [-Wabsolute-value]
target-tricore/op_helper.c:1249:19: warning:
  taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
  has no effect [-Wabsolute-value]
target-tricore/op_helper.c:1297:24: warning:
  taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
  has no effect [-Wabsolute-value]
target-tricore/op_helper.c:1298:25: warning:
  taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
  has no effect [-Wabsolute-value]
target-tricore/op_helper.c:1299:19: warning:
  taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
  has no effect [-Wabsolute-value]

Fix also the divisor which was taken from the wrong register
(thanks to Peter Maydell for this hint).

Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Message-Id: <1425739412-8144-1-git-send-email-sw@weilnetz.de>
Signed-off-by: NBastian Koppelmann <kbastian@mail.uni-paderborn.de>

# gpg: Signature made Mon Mar 23 16:51:45 2015 GMT using RSA key ID AAFC390E
# gpg: Can't check signature: public key not found

* remotes/jnsnow/tags/ide-pull-request:
  ahci-test: improve rw buffer patterns
  ahci: Fix sglist offset manipulation for BE machines
  ide: fix cmd_read_pio when nsectors > 1
  ide: fix cmd_write_pio when nsectors > 1
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

My pattern was cyclical every 256 bytes, so it missed a fairly obvious
failure case. Add some rand() pepper into the test pattern, and for large
patterns that exceed 256 sectors, start writing an ID per-sector so that
we never generate identical sector patterns.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Tested-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1426811056-2202-5-git-send-email-jsnow@redhat.com

This does not bother DMA, because DMA generally transfers
the entire SGList in one shot if it can.

PIO, on the other hand, tries to transfer just one sector
at a time, and will make multiple visits to the sglist
to fetch memory addresses.

Fix the memory address calculaton when we have an offset
by moving the offset addition OUTSIDE of the le64_to_cpu
calculation.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Tested-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1426811056-2202-4-git-send-email-jsnow@redhat.com

Similar to the cmd_write_pio fix, update the nsector count and
ide sector before we invoke ide_transfer_start.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Tested-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1426811056-2202-3-git-send-email-jsnow@redhat.com

We need to adjust the sector being written to
prior to calling ide_transfer_start, otherwise
we'll write to the same sector again.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Tested-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1426811056-2202-2-git-send-email-jsnow@redhat.com

linux-user patches for 2.3-rc1

# gpg: Signature made Mon Mar 23 13:51:56 2015 GMT using RSA key ID DE3C9BC0
# gpg: Good signature from "Riku Voipio <riku.voipio@iki.fi>"
# gpg:                 aka "Riku Voipio <riku.voipio@linaro.org>"

* remotes/riku/tags/pull-linux-user-20150323:
  linux-user: fix broken cpu_copy()
  linux-user: fix emulation of splice syscall
  linux-user/main.c: Remove redundant end_exclusive() in arm_kernel_cmpxchg64_helper()
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

New threads always point at the same env which is incorrect and usually
leads to a crash.
Signed-off-by: NLeon Alrae <leon.alrae@imgtec.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>

The second and fourth argument are in/out parameters, store them back
after the syscall.  Also, the fourth argument was mishandled, and EFAULT
handling was missing.
Signed-off-by: NAndreas Schwab <schwab@suse.de>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>

start/end_exclusive() need be pairs, except the start_exclusive() in
stop_all_tasks() which is only used by force_sig(), which will be abort.
So at present, start_exclusive() in stop_all_task() need not be paired.

queue_signal() may call force_sig(), or return after kill pid (or queue
signal). If could return from queue_signal(), stop_all_task() would not
be called in time, the next end_exclusive() would be issue.

So in arm_kernel_cmpxchg64_helper() for ARM, need remove end_exclusive()
after queue_signal(). The related commit: "97cc7560 linux-user: Implement
new ARM 64 bit cmpxchg kernel helper".
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NRiku Voipio <riku.voipio@linaro.org>

X86 queue 2015-03-19

# gpg: Signature made Thu Mar 19 19:40:17 2015 GMT using RSA key ID 984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>"
# 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: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D C5A6

* remotes/ehabkost/tags/x86-pull-request:
  target-i386: Haswell-noTSX and Broadwell-noTSX
  Revert "target-i386: Disable HLE and RTM on Haswell & Broadwell"
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Merge remote-tracking branch 'remotes/ehabkost/tags/work/numa-verify-cpus-pull-request' into staging

NUMA queue 2015-03-19

# gpg: Signature made Thu Mar 19 19:25:53 2015 GMT using RSA key ID 984DC5A6
# gpg: Can't check signature: public key not found

* remotes/ehabkost/tags/work/numa-verify-cpus-pull-request:
  numa: Print warning if no node is assigned to a CPU
  pc: fix default VCPU to NUMA node mapping
  numa: introduce machine callback for VCPU to node mapping
  numa: Reject configuration if CPU appears on multiple nodes
  numa: Reject CPU indexes > max_cpus
  numa: Fix off-by-one error at MAX_CPUMASK_BITS check
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

usb: bugfix collection.

# gpg: Signature made Fri Mar 20 07:51:19 2015 GMT using RSA key ID D3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"

* remotes/kraxel/tags/pull-usb-20150320-1:
  ehci: fix segfault when hot-unplugging ehci controller
  ohci: fix resource cleanup leak
  uhci: fix segfault when hot-unplugging uhci controller
  hw/usb: Include USB files only if necessary
  usb/dev-storage: Avoid qerror_report_err() outside QMP handlers
  usb/dev-storage: Fix QMP device_add missing encryption key failure
  monitor usb: Inline monitor_read_bdrv_key_start()'s first part
  monitor: Plug memory leak in monitor_read_bdrv_key_start()
  monitor: Drop dead QMP check from monitor_read_password()
  uhci: Convert to realize
  ohci: Complete conversion to realize
  usb: Improve companion configuration error messages
  usb: Propagate errors through usb_register_companion()
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

When hot-unplugging the usb controllers (ehci/uhci),
we have to clean all resouce of these devices,
involved registered reset handler. Otherwise, it
may cause NULL pointer access and/or segmentation fault
if we reboot the guest os after hot-unplugging.

Let's hook up reset via DeviceClass->reset() and drop
the qemu_register_reset() call. Then Qemu will register
and unregister the reset handler automatically.

Cc: qemu-stable <qemu-stable@nongnu.org>
Reported-by: NLidonglin <lidonglin@huawei.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

When hot-unplugging the usb controllers (ehci/uhci),
we have to clean all resouce of these devices,
involved registered reset handler. Otherwise, it
may cause NULL pointer access and/or segmentation fault
if we reboot the guest os after hot-unplugging.

Let's hook up reset via DeviceClass->reset() and drop
the qemu_register_reset() call. Then Qemu will register
and unregister the reset handler automatically.

Ohci does't support hotplugging/hotunplugging yet, but
existing resource cleanup leak logic likes ehci/uhci.

Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

When hot-unplugging the usb controllers (ehci/uhci),
we have to clean all resouce of these devices,
involved registered reset handler. Otherwise, it
may cause NULL pointer access and/or segmentation fault
if we reboot the guest os after hot-unplugging.

Let's hook up reset via DeviceClass->reset() and drop
the qemu_register_reset() call. Then Qemu will register
and unregister the reset handler automatically.

Cc: qemu-stable <qemu-stable@nongnu.org>
Reported-by: NLidonglin <lidonglin@huawei.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

With the Intel microcode update that removed HLE and RTM, there will be
different kinds of Haswell and Broadwell CPUs out there: some that still
have the HLE and RTM features, and some that don't have the HLE and RTM
features. On both cases people may be willing to use the pc-*-2.3
machine-types.

So, to cover both cases, introduce Haswell-noTSX and Broadwell-noTSX CPU
models, for hosts that have Haswell and Broadwell CPUs without TSX support.
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

This reverts commit 13704e4c.

With the Intel microcode update that removed HLE and RTM, there will be
different kinds of Haswell and Broadwell CPUs out there: some that still
have the HLE and RTM features, and some that don't have the HLE and RTM
features. On both cases people may be willing to use the pc-*-2.3
machine-types.

So instead of making the CPU model results confusing by making it depend
on the machine-type, keep HLE and RTM on the existing Haswell and
Broadwell CPU models. The plan is to introduce "Haswell-noTSX" and
"Broadwell-noTSX" CPU models later, for people who have CPUs that don't
have TSX feature available.
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

We need all possible CPUs (including hotplug ones) to be present in the
SRAT when QEMU starts. QEMU already does that correctly today, the only
problem is that when a CPU is omitted from the NUMA configuration, it is
silently assigned to node 0.

Check if all CPUs up to max_cpus are present in the NUMA configuration
and warn about missing CPUs.

Make it just a warning, to allow management software to be updated if
necessary. In the future we may make it a fatal error instead.

Command-line examples:

* Correct, no warning:

  $ qemu-system-x86_64 -smp 2,maxcpus=4
  $ qemu-system-x86_64 -smp 2,maxcpus=4 -numa node,cpus=0-3

* Incomplete, with warnings:

  $ qemu-system-x86_64 -smp 2,maxcpus=4 -numa node,cpus=0
  qemu-system-x86_64: warning: CPU(s) not present in any NUMA nodes: 1 2 3
  qemu-system-x86_64: warning: All CPU(s) up to maxcpus should be described in NUMA config

  $ qemu-system-x86_64 -smp 2,maxcpus=4 -numa node,cpus=0-2
  qemu-system-x86_64: warning: CPU(s) not present in any NUMA nodes: 3
  qemu-system-x86_64: warning: All CPU(s) up to maxcpus should be described in NUMA config
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
---
v1 -> v2: (no changes)

v2 -> v3:
 * Use enumerate_cpus() and error_report() for error message
 * Simplify logic using bitmap_full()

v3 -> v4:
 * Clarify error message, mention that all CPUs up to
   maxcpus need to be described in NUMA config

v4 -> v5:
 * Commit log update, to make problem description clearer

Since commit
   dd0247e0 pc: acpi: mark all possible CPUs as enabled in SRAT
Linux kernel actually tries to use CPU to Node mapping from
QEMU provided SRAT table instead of discarding it, and that
in some cases breaks build_sched_domains() which expects
sane mapping where cores/threads belonging to the same socket
are on the same NUMA node.

With current default round-robin mapping of VCPUs to nodes
guest ends-up with cores/threads belonging to the same socket
being on different NUMA nodes.

For example with following CLI:

   qemu-system-x86_64 -m 4G \
         -cpu Opteron_G3,vendor=AuthenticAMD \
         -smp 5,sockets=1,cores=4,threads=1,maxcpus=8 \
         -numa node,nodeid=0 -numa node,nodeid=1

2.6.32 based kernels will hang on boot due to incorrectly built
sched_group-s list in update_sd_lb_stats()

Replacing default mapping with a manual, where VCPUs belonging to
the same socket are on the same NUMA node, fixes the issue for
guests which can't handle nonsense topology i.e. changing CLI to:
  -numa node,nodeid=0,cpus=0-3 -numa node,nodeid=1,cpus=4-7

So instead of simply scattering VCPUs around nodes, provide
callback to map the same socket VCPUs to the same NUMA node,
which is what guests would expect from a sane hardware/BIOS.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Current default round-robin way of distributing VCPUs among
NUMA nodes might be wrong in case on multi-core/threads
CPUs. Making guests confused wrt topology where cores from
the same socket are on different nodes.

Allow a machine to override default mapping by providing
 MachineClass::cpu_index_to_socket_id()
callback which would allow it group VCPUs from a socket
on the same NUMA node.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Each CPU can appear in only one NUMA node on the NUMA config. Reject
configuration if a CPU appears in multiple nodes.
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

CPU index is always less than max_cpus, as documented at sysemu.h:

> The following shall be true for all CPUs:
>   cpu->cpu_index < max_cpus <= MAX_CPUMASK_BITS

Reject configuration which uses invalid CPU indexes.
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Fix the CPU index check to ensure we don't go beyond the size of the
node_cpu bitmap.

CPU index is always less than MAX_CPUMASK_BITS, as documented at
sysemu.h:

> The following shall be true for all CPUs:
>   cpu->cpu_index < max_cpus <= MAX_CPUMASK_BITS
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>